nanog mailing list archives

RE: NANOG Digest, Vol 26, Issue 142

From: "Stephen Tandy" <stephen.tandy () trigenis com>
Date: Tue, 30 Mar 2010 14:09:32 +0100



Sent from my Windows® phone.

-----Original Message-----
From: nanog-request () nanog org <nanog-request () nanog org>
Sent: 30 March 2010 13:00
To: nanog () nanog org <nanog () nanog org>
Subject: NANOG Digest, Vol 26, Issue 142

Send NANOG mailing list submissions to
        nanog () nanog org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
        nanog-request () nanog org

You can reach the person managing the list at
        nanog-owner () nanog org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

   1. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4
      ANYCAST   setup) (Robert Kisteleki)
   2. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4
      ANYCAST   setup) (Phil Regnauld)
   3. Re: IPv4 ANYCAST setup (Jens Link)
   4. Re: IPv4 ANYCAST setup (bmanning () vacation karoshi com)
   5. Re: IPv4 ANYCAST setup (Tony Finch)
   6. Re: Useful URL for network operators (Valdis.Kletnieks () vt edu)
   7. RE: Auto MDI/MDI-X + conference rooms + bored == loop
      (William Mullaney)


----------------------------------------------------------------------

Message: 1
Date: Tue, 30 Mar 2010 11:37:49 +0200
From: Robert Kisteleki <robert () ripe net>
Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4
        ANYCAST setup)
To: nanog () nanog org
Message-ID: <4BB1C66D.7000808 () ripe net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I must observe that these are not really the links you'd want to give your 
end users to check out. Their audience is very different. While the article 
on RIPE Labs comes close, they don't really answer the "does it work or does 
it not?" question with a green/red light, and they don't provide a good 
explanation to the audience Randy is referring to.

Robert


On 2010.03.30. 11:29, Phil Regnauld wrote:

Randy Bush (randy) writes:


i.e. what can we do to maximize the odds that the victim will quickly
find the perp, as opposed to calling our our tech support lines?


      Ah yes, there was the second good reason for actually helping netops
      and security officers :)

      Tools:

      https://www.dns-oarc.net/oarc/services/replysizetest

      https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources,
      under troubleshooting:
              http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues
              http://secspider.cs.ucla.edu/

      Info sheets:

      
http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010
      (click English, top right)

      ... plenty of links there too.

      Cheers,
      Phil





------------------------------

Message: 2
Date: Tue, 30 Mar 2010 11:52:27 +0200
From: Phil Regnauld <regnauld () nsrc org>
Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4
        ANYCAST setup)
To: Robert Kisteleki <robert () ripe net>
Cc: nanog () nanog org
Message-ID: <20100330095226.GE24147 () macbook catpipe net>
Content-Type: text/plain; charset=us-ascii

Robert Kisteleki (robert) writes:

I must observe that these are not really the links you'd want to
give your end users to check out. Their audience is very different.
While the article on RIPE Labs comes close, they don't really answer
the "does it work or does it not?" question with a green/red light,
and they don't provide a good explanation to the audience Randy is
referring to.


        Fair enough.  Some simple "check your DNS reply size test [what is this ?]"
        page ought to be set up, with a simple explanagtion.
        "checkmydns.org" is available.  If I get 5 minutes... :)





------------------------------

Message: 3
Date: Tue, 30 Mar 2010 11:58:16 +0200
From: Jens Link <lists () quux de>
Subject: Re: IPv4 ANYCAST setup
To: nanog () nanog org
Message-ID: <87mxxqb07b.fsf () bowmore quux de>
Content-Type: text/plain; charset=us-ascii

"Kevin Oberman" <oberman () es net> writes:

He said that if the protocols would not handle blocked 53/tcp, the
protocols would have to be changed. Opening the port was simply not
open to discussion.


Let me guess: They also completely blocked ICMP. I always tell these
customers to switch to IPv6 real fast and to turn of ICMPv6 to make
their networks really secure. ;-)

I will say that these were at federal government facilities. I hope the
commercial world is a bit more in touch with reality.


You can find clueless people everywhere. 

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264         |
| http://www.quux.de | http://blog.quux.de   | jabber: jenslink () guug de |
-------------------------------------------------------------------------



------------------------------

Message: 4
Date: Tue, 30 Mar 2010 10:05:27 +0000
From: bmanning () vacation karoshi com
Subject: Re: IPv4 ANYCAST setup
To: Randy Bush <randy () psg com>
Cc: "nanog () nanog org" <nanog () nanog org>
Message-ID: <20100330100527.GC30288 () vacation karoshi com.>
Content-Type: text/plain; charset=us-ascii

On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote:

I have talked to multiple security officers (who are generally not  
really knowledgeable on networks) who had 53/tcp blocked and none  
have yet agreed to change it.

patience.  when things really start to break, and the finger of fate  
points at them, clue may arise.

36 days until all root servers have DNSSEC data, at which point large
replies become normal.


are end user tools, i.e. a web click a button, available so they can
test if they are behind a clueless security id10t?


        no - in part because using a browser to debug DNS involves
        a third app (and likly a third/forth) platform.

        the nifty OARC testpoint is nearly worthless for real operations,
        since its not located at/near a DNS authoritative source.  the
        K testpoint is good, I should prolly put back the one off B.

is there good simple end user docco they are somewhat likely to find
when things break for them?


        not yet.  in part because out of the few simple parts, many, many
        combinations of failure can occur.

        ) MTU strictures:
                v6/v4 tunneling
                v6/v4 MTU
                clamping
                
        ) Fragmenation
                UDP
        ) Port blocking
        ) Resolver Behaviour
                EDNS awareness

i.e. what can we do to maximize the odds that the victim will quickly
find the perp, as opposed to calling our our tech support lines?


        thats a tough call.  as tech support staff, we are almost always
        an outside observer on the path btwn the victim and the perp.
        troubleshooting is going to be problematic.


randy




------------------------------

Message: 5
Date: Tue, 30 Mar 2010 11:53:12 +0100
From: Tony Finch <dot () dotat at>
Subject: Re: IPv4 ANYCAST setup
To: nanog () nanog org
Message-ID:
        <alpine.LSU.2.00.1003301152280.1923 () hermes-2 csi cam ac uk>
Content-Type: TEXT/PLAIN; charset=US-ASCII

"Kevin Oberman" <oberman () es net> writes:

He said that if the protocols would not handle blocked 53/tcp, the
protocols would have to be changed. Opening the port was simply not
open to discussion.


Do they also believe that all DNS replies are less than 512 bytes? :-)

Tony.
-- 
f.anthony.n.finch  <dot () dotat at>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.



------------------------------

Message: 6
Date: Tue, 30 Mar 2010 07:33:39 -0400
From: Valdis.Kletnieks () vt edu
Subject: Re: Useful URL for network operators
To: Jim Mercer <jim () reptiles org>
Cc: nanog () nanog org
Message-ID: <1191.1269948819@localhost>
Content-Type: text/plain; charset="us-ascii"

On Tue, 30 Mar 2010 05:34:06 EDT, Jim Mercer said:

Once again, please ignore Jim Mercer.
He should do more homeworks too.


He's said similar about a number of people who have more operations clue than
he does.  I'd comment, except Woody Allen already did it better:

http://www.youtube.com/watch?v=9wWUc8BZgWE

 a) I have never heard of Randy Bush


That's OK, I encoura.. oh nevermind, it's shooting fish in a barrel. ;)




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
Url : http://mailman.nanog.org/mailman/nanog/attachments/20100330/dfea2bda/attachment-0001.pgp 

------------------------------

Message: 7
Date: Tue, 30 Mar 2010 07:36:04 -0400
From: "William Mullaney" <wmullaney () annese com>
Subject: RE: Auto MDI/MDI-X + conference rooms + bored == loop
To: "Chuck Anderson" <cra () WPI EDU>,  <nanog () nanog org>
Message-ID:
        <CB659FEF50324640B503095DA13FA9F4F65373@COMM02.annese.local>
Content-Type: text/plain;       charset="us-ascii"

We had a school district that had a large number of "dumb" switches in
each class room hanging off real ones.  These would get looped when a
student or staff member plugged a patch cable into two ports on the end
switch, taking down large portions of the network.  It seems Cisco
3500's ignore a BPDU that comes in the same port it comes out.

We switched them to 3750's as part of other upgrades, which eliminated
the BPDU problem (3560's and 3550's also work correctly), RSTP, enabled
port fast, root guard, loop back detection, and storm control.  Then set
the switches to automatically come back in service from err-disable
after 60 seconds or so.

In every single test we did (looping off a dumb switch, looping two
ports on the 3750, looping between two 3750 in different stacks), there
was immediate blocking occurring that prevented any non-sense from
effecting the network.  Of course the little switches get taken out
along with anything connected, but that's really just an indicator of
the need for more drops from real switches.  Additionally, turning on
only one of the features at a time still shut down the port within a
second or so.

I don't really like BPDUGuard when rootguard is available, as I think
other devices should be able to participate in STP so long as they
aren't trying to reconverge the network by grabbing root or becoming a
transit between two building switches.  As for RSTP, it's on for every
switch we deploy unless there is some compelling reason not to do so.  I
have yet to find another switch that will not work even if it only
supports "old" STP.

-WT

-----Original Message-----
From: Chuck Anderson [mailto:cra () WPI EDU] 
Sent: Friday, March 26, 2010 6:09 PM
To: nanog () nanog org
Subject: Auto MDI/MDI-X + conference rooms + bored == loop

Anyone have suggestions on Ethernet LAN loop-prevention?  With the 
advent of Auto MDI/MDI-X ports on switches, it seems way too easy to 
accidentally or maliciously create loops between network jacks.  We 
have bored or inattentive people plugging in patch cords between 
adjacent network jacks.  STP for loop-prevention isn't working so well 
for us.

STP "edge" or "portfast" or "faststart" modes are required for 
end-station ports (with normal STP, DHCP often times out after 30+ 
seconds it takes to go into Forwarding state).  Since the "edge" STP 
mode goes into Forwarding state immediately, there is a period when 
loops will form, causing havok with upstream gear until STP blocks the 
port (if it ever does see below).

"Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet 
switches.  Apparently, many of them don't do any kind of STP at all.  
Recommendations on ones that do STP?

RSTP: is it any better than traditional STP in regards to "edge" ports 
and blocking before a loop gets out of hand?  Or perhaps blocking for 
5-10 seconds before going into Forwarding state, hopefully preventing 
loops before they happen but also allowing DHCP clients to get an 
address without timeouts?  Recommendations on "Desktop" switches that 
do RSTP?

Thanks for your suggestions/discussion.

-- 
- Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)




------------------------------

_______________________________________________
NANOG mailing list
NANOG () nanog org
https://mailman.nanog.org/mailman/listinfo/nanog

End of NANOG Digest, Vol 26, Issue 142
**************************************

Current thread:

RE: NANOG Digest, Vol 26, Issue 142 Stephen Tandy (Mar 30)
- <Possible follow-ups>
- RE: NANOG Digest, Vol 26, Issue 142 Stephen Tandy (Mar 30)
- Re: NANOG Digest, Vol 26, Issue 142 Larry Sheldon (Mar 30)
  - Mindfulness (was Re: NANOG Digest, Vol 26, Issue 142) Anton Kapela (Mar 30)
  - Re: NANOG Digest, Vol 26, Issue 142 Randy Bush (Mar 30)
    - Re: NANOG Digest, Vol 26, Issue 142 Larry Sheldon (Mar 30)