- Test - lists.nanog.org

RE: key change for TCP-MD5
by Bora Akyol 27 Jun '06

27 Jun '06

> > Another potential attack is an attempt to insert information > into a BGP session, such as to introduce bogus routes, or to > even become a "man in the middle" of a BGP session. One issue > that worries me about this is that if this allows routing to > be compromised, then I can figure out how to make money off > of this (and if I can think of it, someone even nastier will > probably also think of this). Of course this would be much > more difficult to pull off, and might require viewing packets > between routers to pull off, but if pulled off and not > quickly detected could be unfortunate. > > Ross This one is hard to pull off. I think the general conclusion a couple years ago in the study that Sean Convery and Matt Franz did was that it was less work to try to own the router or buy your own AS ;) Bora

4 3

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

27 Jun '06

At 12:12 PM 6/20/2006 -0700, Bora Akyol wrote: >The draft allows you to have a set of keys in your keychain and >the implementation tries all of them before declaring the segment >as invalid. DoS against routers is of course a major concern. Using encryption has the potential of making DoS worse, in the sense that the amount of processing that a bogus packet can cause is increased by the amount of processing needed to check the authentication. If the router needs to check multiple keys in the keychain before declaring the segment as invalid, then this multiplies the effect of the DOS by the number of keys that need to be checked. >No time synchronization required. No BGP message required. > >The added cost for CPU-bound systems is that they have to try >(potentially) multiple keys before getting the **right** key >but in real life this can be easily mitigated by having a rating >system on the key based on the frequency of success. This mitigates the effect of authenticating valid packets. However, this does not appear to help at all in terms of minimizing the DOS effect of an intentional DoS attack that uses authenticated packets (with the processing time required to check the keys the intended damage of the attack). Ross > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > > Behalf Of Iljitsch van Beijnum > > Sent: Monday, June 19, 2006 10:22 AM > > To: Randy Bush > > Cc: NANOG list > > Subject: Re: key change for TCP-MD5 > > > > > > On 19-jun-2006, at 19:10, Randy Bush wrote: > > > > >>> try reading more carefully > > > > >> Didn't help... > > > > > how sad, as the whole document is about how to usefully be able to > > > introduce and roll to new keys without agreeing on a narrow time. > > > > Well, as you can tell from my message just now, I don't think > > going from agreeing on a narrow time to agreeing on a wider > > time is worth the trouble, especially since by adding a BGP > > message it would be possible to roll over if and as soon as > > both sides are ready, removing the "wait for some time and > > then see whether the other end really installed the new key" > > part from the proceedings. > > > >

7 9

Who wants to be in charge of the Internet today?
by Sean Donelan 26 Jun '06

26 Jun '06

http://online.wsj.com/article/SB115102893799688389.html In Event of Big Web Disruption, U.S. Is Ill-Prepared, Study Says By VAUHINI VARA June 23, 2006; Page B2 The U.S. is poorly prepared for a major disruption of the Internet, according to a study that an influential group of chief executives will publish today. The Business Roundtable, composed of the CEOs of 160 large U.S. companies, said neither the government nor the private sector has a coordinated plan to respond to an attack, natural disaster or other disruption of the Internet. While individual government agencies and companies have their own emergency plans in place, little coordination exists between the groups, according to the study. "It's a matter of more clearly defining who has responsibility," said Edward Rust Jr., CEO of State Farm Mutual Automobile Insurance Co., who leads the Roundtable's Internet-security effort. [...]

15 14

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