June 2006 - Test - lists.nanog.org

RE: Nationwide Routing issues with Wiltel
by Daniel S. Laughland 26 Jun '06

26 Jun '06

We're in Milwaukee and having problems connecting to some sites in New England. Tracert shows it going through some Level 3 routers, and then it stops. I called Level 3 and they're blaming bad weather, but didn't give me any details. Are you seeing anything similar? ________________________________ From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Vincent India Sent: Monday, June 26, 2006 3:39 PM To: nanog(a)merit.edu Subject: Nationwide Routing issues with Wiltel Anyone experiencing problems with Wiltel Backbone, or know of any issues with the Wiltel Backbone? I called their NOC and was told they are experiencing a nationwide routing problem that they are working on but couldn't get any further details?

1 0

LDMI?
by Fox,Thomas 26 Jun '06

26 Jun '06

Anyone on the list using LDMI? We had a 4 hour outage (voice and data) this morning, and now data outage this afternoon. Any word on the street? --- [This E-mail scanned for viruses by Declude Virus]

1 0

Re: Multihomed to 2 ISPs - Load Balance?
by John Smith 26 Jun '06

26 Jun '06

Replying to what most of the offline replies that i received said: >> We wish to load balance the traffic for a block/range of IP addresses >> that we learn via BGP4 from our two upstream providers. The problem is >> that my favorite vendor does not let me install ECMP routes in case of >> routes learnt from extrnal BGP peers. Assuming that we are able to >> install EBGP ECMP routes, how do we advertise this information to our >> downstream peers? As far as my working knowledge of BGP4 goes, it wouldnt >> let me do this. >> I wish to understand how other network operators do this? > You don't, not usually anyway. You advertise the best path to your > downstreams. If you want to 'load balance' per packet or otherwise to one > or more upstreams that's an internal/your AS decision only. There's > nothing to tell the downstreams about from BGP's point of view. > I think there is a need to tell my downstream peers about ASes the traffic is gonna go through. I'm thinking wildly, and it may not make a lot of sense but heres the scenario i have in mind: You load balance (per stream which is usually what most of the vendors do) and you distribute your traffic through ASes 10 and 20. Now you are advertising only one BGP path, say the one through AS 10. Isnt this a problem? Isnt "Advertise what you yourself use" one of the basic shibboleths of BGP or routing for that matter? Regards, John > How exactly you loadbalance the outgoing traffic totally depends on your > hardware of choice. > > You can, if you wish, send me a message offline and i will collate all > the information that i receive and send out a consolidated reply for the > benefit of others to this mailing list. > Thanks, > John > > > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler

6 7

RE: key change for TCP-MD5
by Ross Callon 26 Jun '06

26 Jun '06

At 04:23 PM 6/20/2006 -0700, Bora Akyol wrote: >...The DOS is a concern whether you have a valid key or not, correct? Yes, People who do NOT have a valid key can certainly launch DOS attacks. >I can DOS the router with fake packets that it needs to verify as long >as I want. Yes, but the attack needs to get past whatever packet filters (ACLs) are between them and the CPU that they are trying to overwhelm. This might include packet filters on ingress to whatever network the attacker is in, packet filters on ingress to the network of the victim, or on ingress to the router under attack. >All the multiple keys do is to decrease the cost of the DOS. Yes >...For example, >if we allow 4 keys at a time and the router dies at a 100 Mbps >attack traffic, now it will die at 25 Mbps. While this may look like a >big >deal, I think the dark side has enough firepower that essentially 25 >equals 100. There are of course two multiplicative effects: The effect of using authentication at all, and the effect of having multiple keys active at once. However, yes, the effect of having "n" keys active at once is no worse than n times the effect of using authentication. >If DOS is such a large concern, IPSEC to an extent can be used >to mitigate against it. And IKEv1/v2 with IPSEC is not the >horribly inefficient mechanism it is made out to be. In practice, >it is quite easy to use. Well, this one comment is the one that I don't understand. I don't see how IPSEC mitigates against DOS attacks. In fact, it seems to make things worse, since it hides the TCP header. If a packet is authenticated at the TCP level, then the attack packet needs to get past (hopefully line rate) packet filters on the IP header, and some fields in the TCP header before it can contribute to the DOS attack (but it can still contribute to DoS even if the authentication fails). If the TCP sequence number is out of range, then a smart implementation may indeed discard the packet before checking the authentication, but it still likely has gotten past the packet filters and gotten to the CPU. If a packet is authenticated using IPSEC (between IP and TCP), then it only needs to get past the IP packet filters before it can contribute to the DOS, and doesn't need to get past whatever checks occur at the TCP level (including not having to get past the sequence number check prior to having the authentication checked). Ross

4 4

RE: key change for TCP-MD5
by Barry Greene (bgreene) 24 Jun '06

24 Jun '06

At the same time, you are not going to find the SP core swapping out their equipment for hardware with crypto chips. SPs do not seem to want to pay for this sort of addition. So even new equipment is not getting hardware crypto that can be used. So a BGP IPSEC option has to work with what hardware we've got deployed today - not wishing the community would "just upgrade." > -----Original Message----- > From: Bora Akyol [mailto:bora@broadcom.com] > Sent: Friday, June 23, 2006 2:02 PM > To: Valdis.Kletnieks(a)vt.edu > Cc: Barry Greene (bgreene); Ross Callon; nanog(a)merit.edu > Subject: RE: key change for TCP-MD5 > > Assumptions, assumptions. > > If your IPSEC is being done in hardware and you have > appropriate QoS mechanisms in your network, you will probably > not be able to pass your best effort traffic but the rest > should be OK. > > Can we get back to the regularly scheduled programming > instead of throwing big numbers around? > > Barry had a point, if you do IPSEC stupidly, it does not protect you. > If you pay attention to detail, it does help. It is not the panacea. > > For the purpose of securing BGP, I think IPSEC is easy to > configure (at least on IOS which is what I'm used to), and > will do the job. And for this application, I don't see why > cert's can't be used either. > > Regards > > Bora > > > > -----Original Message----- > > From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > > Sent: Friday, June 23, 2006 1:46 PM > > To: Bora Akyol > > Cc: Barry Greene (bgreene); Ross Callon; nanog(a)merit.edu > > Subject: Re: key change for TCP-MD5 > > > > On Fri, 23 Jun 2006 13:35:20 PDT, Bora Akyol said: > > > > > The validity of your statement depends tremendously on > how IPSEC is > > > implemented. > > > > If 113 million packets all show up at once, you're going to get > > DoS'ed, whether or not you have IPSEC enabled. > > >

2 1

RE: key change for TCP-MD5
by Barry Greene (bgreene) 24 Jun '06

24 Jun '06

> If DOS is such a large concern, IPSEC to an extent can be > used to mitigate against it. And IKEv1/v2 with IPSEC is not > the horribly inefficient mechanism it is made out to be. In > practice, it is quite easy to use. IPSEC does nothing to protect a network device from a DOS attack. You know that. DOS prevention on a network device needs to happen before the TCP/Packet termination - not the Key/MD5/IPSEC stage. The signing or encrypting of the BGP message protects against Man in the Middle and replay attacks - not DOS attacks. Once a bad packet gets terminated, your DOS stress on the router kicks in (especially on ASIC/NP routers). The few extra CPU cycles it takes for walking through keys or IPSEC decrypt are irrelevant to the router's POV. You SOL if a miscreant can get a packet through your classification & queuing protections on the router and have it terminated. The key to DOS mitigation on a network device is to have many fields in the packet to classify as possible before the TCP/Packet termination. The more you have to classify on, the more granular you can construct your policy. This is one of the reasons for GTSM - which adds one more field (the IP packet's TTL) to the classification options. Yes Jared - our software does the TTL after the MD5, but the hardware implementations does the check in hardware before the packet gets punted to the receive path. That is exactly where you need to do the classification to minimize DOS on a router - as close to the point where the optical-electrical-airwaves convert to a IP packet as possible.

6 7

RE: key change for TCP-MD5
by Barry Greene (bgreene) 24 Jun '06

24 Jun '06

> Why couldn't the network device do an AH check in hardware > before passing the packet to the receive path? If you can > get to a point where all connections or traffic TO the router > should be AH, then, that will help with DOS. There is no push from the operators to look at AH check or the SPI check in before the receive path punt. The push was to get something the lowest common denominator engineering in the NOC can handle with a BGP key roll. Hence draft-bonica-tcp-auth. Many operators. Build on the operator's requirements. Build on experience with similar techniques. Three vendors agree - all with working code. > If you can limit what devices _SHOULD_ talk to the router and > at least define some subset of that from which you demand AH > on every packet, that helps but isn't a complete solution. This is a major path. Everything from recoloring the packets coming into your network to BCP38 to new tricks. But that is a different conversation.

1 0

RE: key change for TCP-MD5
by Barry Greene (bgreene) 24 Jun '06

24 Jun '06

This "RFC1918 for control plane/management plane" technique is vulnerable to a TCP reflection attack. The miscreants know about it. So the assumption that the chance of a RFC 1918 packet reaching your router being "zero" is not something an you should assume. > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Iljitsch van Beijnum > Sent: Friday, June 23, 2006 4:18 PM > To: Owen DeLong > Cc: NANOG list > Subject: Re: key change for TCP-MD5 > > > On 24-jun-2006, at 0:43, Owen DeLong wrote: > > > Why couldn't the network device do an AH check in hardware before > > passing the packet to the receive path? If you can get to a point > > where all connections or traffic TO the router should be AH, then, > > that will help with DOS. > > If you care that much, why don't you just add an extra > loopback address, give it an RFC 1918 address, have your peer > talk BGP towards that address and filter all packets towards > the actual interface address of the router? > > The chance of an attacker sending an RFC 1918 packet that > ends up at your router is close to zero and even though the > interface address still shows up in traceroutes etc it is > bullet proof because of the filters. > > (This works even better with IPv6 link local addresses, those > are guaranteed to be unroutable.) >

1 0

RE: key change for TCP-MD5
by Barry Greene (bgreene) 24 Jun '06

24 Jun '06

Walk through the code with the current MD5 spec. You need to terminate the TCP session, check the MD5, then do the next checks. That is why we're doing TTL check for GTSM and other classifying/queuing before the TCP session termination. In the big equipment that ranges from specialized ASIC checks, to raw queue classifiers, to ACLs .... All before the packet gets punted out of the forwarding chip to the Route Processor. In other equipment you do the check on the Line Card's CPU after the punt - compartmentizing the impact of an attack. There is even code in the 'coding queue' to do the check on CPU routers before you terminate (still get the CPU clock cycle hit for dropping the packet). Granted, you need to put this in context of how vendors should be building security into their devices - layered - with a combination of classification (i.e. ACLs), queuing (containing the impact), and systems practices. So go back to the instigating presentation: http://www.nanog.org/mtg-0302/gill.html Also check on one vendor's roadmap: ftp://ftp-eng.cisco.com/cons/isp/security/BGP-Security/GTSM.pdf So lets keep focused on the right issue - can you TTL filter before the TCP session terminates vs worrying over the order of the multitude of checks which take up processing the TCP packet. > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Todd Underwood > Sent: Friday, June 23, 2006 1:43 PM > To: nanog(a)merit.edu > Subject: Re: key change for TCP-MD5 > > > > > On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene > (bgreene) wrote: > > > > Yes Jared - our software does the TTL after the MD5, but > the hardware > > implementations does the check in hardware before the packet gets > > punted to the receive path. That is exactly where you need > to do the > > classification to minimize DOS on a router - as close to the point > > where the optical-electrical-airwaves convert to a IP > packet as possible. > > i'm not that bright, so maybe i'm missing something, but i've > heard this claim from cisco people before and never understood it. > > just to clarify: you're saying that doing the (expensive) > md5 check before the (almost free) ttl check makes sense because that > *minimizes* the DOS vectors against a router? can someone > walk me through the logic here using small words? i am > obviously not able to follow this due to my distance from the > "optical-electrical-airwaves". > > t. > > > -- > _____________________________________________________________________ > todd underwood +1 603 643 9300 x101 > renesys corporation chief of > operations & security > todd(a)renesys.com > http://www.renesys.com/blog/todd.shtml >

1 0

Multihomed to 2 ISPs - Load Balance?
by John Smith 23 Jun '06

23 Jun '06

Hi Fellow Nanogers: I searched the archives and could not find anything that really matches with my requirement. I have been stalking this mailing list since quite some time and its extremely rare that i post. We are multihomed and connected to the Internet via two upstream providers. The initial idea was to get more bandwidth and redundancy. Now, we're past this stage and want to try out something different. Please note that we also provide transit services to a few downstream providers. We wish to load balance the traffic for a block/range of IP addresses that we learn via BGP4 from our two upstream providers. The problem is that my favorite vendor does not let me install ECMP routes in case of routes learnt from extrnal BGP peers. Assuming that we are able to install EBGP ECMP routes, how do we advertise this information to our downstream peers? As far as my working knowledge of BGP4 goes, it wouldnt let me do this. I wish to understand how other network operators do this? You can, if you wish, send me a message offline and i will collate all the information that i receive and send out a consolidated reply for the benefit of others to this mailing list. Thanks, John

1 0