Re: key change for TCP-MD5
On 26-jun-2006, at 2:06, Niels Bakker wrote: The reason IPsec helps against a DoS against the CPU is that it has an anti replay counter. IPsec implementations are supposed to maintain a window, not unlike a TCP window, that allows them to reject packets with an anti replay counter that's too far behind or ahead of the last seen packets. So in order to make a packet reach the CPU an attacker has to observe or guess an acceptable value for the anti replay counter. Actually, no. In a router you can easily filter away all IP packets not destined to port 25 to a certain host (for, say, a mail server). However, if those packets are IPsec encrypted, these TCP headers are unavailable to routers in the path. You can't have it both ways: either you encrypt the packet so that nobody can look inside it, or you don't and people can. But we weren't talking about encryption. Or about filtering packets that go _through_ a router. What we were talking about was using the IPsec authentication on BGP sessions and whether that's better than using TCP with MD5 in relation to DoS attacks.
Re: key change for TCP-MD5
On Tue, 20 Jun 2006 17:06:27 -0400, Ross Callon [EMAIL PROTECTED] wrote: 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. You're quite right, and the next version of the draft contains the following additional text in the Security Considerations: Having multiple keys makes CPU denial of service attacks easier. This suggests that keeping the overlap period reasonably short is a good idea. In addition, the Generalized TTL Security Mechanism xref target=RFC3682 /, if applicable to the local topology, can help. Note that there would almost never be more than two keys in existence at any one time in any event. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
backbone threats [Re: key change for TCP-MD5]
On Wed, 21 Jun 2006, Richard A Steenbergen wrote: There is a fine line between being dilligent about security, and wasting your time trying to solve problems that don't exist, which I think has been crossed in the discussion. While TCP-MD5 could be useful in some cases (mainly in Internet Exchanges), I mostly agree with RAS that the big picture isn't necessarily clear. Hence, this is my chance to plug my view of it: http://www.ietf.org/internet-drafts/draft-savola-rtgwg-backbone-attacks-01.txt It's a short document, less than 15 pages. Comments are welcome. The goal of the document is to be able to better convey the real story both between the operator-operator and operator-IETF interfaces :-) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: key change for TCP-MD5
* [EMAIL PROTECTED] (Iljitsch van Beijnum) [Wed 21 Jun 2006, 19:05 CEST]: The reason IPsec helps against a DoS against the CPU is that it has an anti replay counter. IPsec implementations are supposed to maintain a window, not unlike a TCP window, that allows them to reject packets with an anti replay counter that's too far behind or ahead of the last seen packets. So in order to make a packet reach the CPU an attacker has to observe or guess an acceptable value for the anti replay counter. Actually, no. In a router you can easily filter away all IP packets not destined to port 25 to a certain host (for, say, a mail server). However, if those packets are IPsec encrypted, these TCP headers are unavailable to routers in the path. I do not expect a complete IPsec implementation in the filtering engines of routers, nor that they be able to keep track of window sizes in specific conversations (after all, they don't get to see RST packets either). Web servers generally do not come with hardware-based filtering capabilities to protect the CPU. -- Niels.
RE: key change for TCP-MD5
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.)
RE: key change for TCP-MD5
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Underwood Sent: Friday, June 23, 2006 1:43 PM To: nanog@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 corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
RE: key change for TCP-MD5
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:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 2:02 PM To: [EMAIL PROTECTED] Cc: Barry Greene (bgreene); Ross Callon; nanog@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 1:46 PM To: Bora Akyol Cc: Barry Greene (bgreene); Ross Callon; nanog@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.
RE: key change for TCP-MD5
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.
Re: key change for TCP-MD5
On 24-jun-2006, at 1:34, Patrick W. Gilmore wrote: 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. Why is this better than using the TTL hack? Which is easier to configure, and at least as secure. There are several tradeoffs. GTSM (or TTL hack) requires that both ends implement it and this check may or may not be inexpensive. (Looking at the CPU stats when running with MD5 and then looking up how fast MD5 is supposed to be processed on much older hardware doesn't give me much confidence in router code efficiency.) If you're truly paranoid, making sure that as few people as possible can enter packets into your router's CPU input queue makes a lot of sense. I prefer having a regular next hop address that shows up in traceroutes and can generate PMTUD packets but if you move the BGP session to some other address there is no need for the interface address to ever receive any packets. That's a lot better than expending resources on AH processing, which I was replying to. RFC 1918 are an obvious choice for the addresses terminating the BGP session because they're mostly unroutable by default, but an address range that's properly filtered by your peer is even better. And if you're on a public peering LAN (internet exchange) obviously you'll want to have static ARP and MAC forwarding table entries.
Re: key change for TCP-MD5
On Sat, Jun 24, 2006 at 02:51:57AM -0700, Barry Greene (bgreene) wrote: 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. As with everything else, it needs to actually add useful features that makes a SP's life easier, not just be another vector for an extra line item and a higher total on the router invoice. So a BGP IPSEC option has to work with what hardware we've got deployed today - not wishing the community would just upgrade. SPs don't see any tangile benefit in BGP IPSEC (and legitimately so), so this will clearly not be a driving factor for them. I guarantee you if you solve a real problem (like say authenticating and managing authorized prefix announcements) and make it faster/better because the router has hardware crypto available, folks will actually start buying new RPs/etc. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: key change for TCP-MD5
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.
RE: key change for TCP-MD5
-Original Message- From: Barry Greene (bgreene) [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 11:50 AM To: Bora Akyol; Ross Callon; nanog@merit.edu Subject: RE: key change for TCP-MD5 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. Barry The validity of your statement depends tremendously on how IPSEC is implemented. Bora
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 corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
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. pgpRRK8AbWIKX.pgp Description: PGP signature
Re: key change for TCP-MD5
On Fri, Jun 23, 2006 at 04:43:29PM -0400, Todd Underwood wrote: 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. As I parsed Barry's post, he was saying that Cisco currently does the wrong thing today, but that some day when they actually support doing the check in hardware, that will be the right place to do it. (aka duh :P) Obviously in a perfect world, you don't want to do the expensive MD5 check anywhere sooner than the last possible moment before you declare the data valid and add it to the socket buffer. I assume that the reason they can't do the check sooner in software is they lack a mechanism to tell the IP or even TCP input code we want to discard these packets if they are less than TTL x. They probably can't make that decision until the packet gets validated by TCP and makes it all the way to BGP code. But, they should still be able to do all of the TCP layer checks which don't require outside information, such as matching the segment to a proper TCB by ip/port/seq #, before doing the MD5 calculation. This makes DoS against MD5 where you don't know the full L4 port #'s and the seq # pretty impossible on its own, without needing to involve the TTL hack. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 1:46 PM To: Bora Akyol Cc: Barry Greene (bgreene); Ross Callon; nanog@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.
Re: key change for TCP-MD5
On Fri, Jun 23, 2006 at 05:01:00PM -0400, Richard A Steenbergen wrote: Obviously in a perfect world, you don't want to do the expensive MD5 check anywhere sooner than the last possible moment before you declare the data valid and add it to the socket buffer. I assume that the reason they can't do the check sooner in software is they lack a mechanism to tell the IP or even TCP input code we want to discard these packets if they are less than TTL x. They probably can't make that decision until the packet gets validated by TCP and makes it all the way to BGP code. Actually I take that back, it should be easy enough to configure a minimum TTL requirement on the TCB through a socket interface. Obviously they're doing something to pass the IP TTL data outside of its normal in_input() function (or whatever passes for such on IOS), so if you've got that data avilable in the tcp_input() code you should be able to do the check after you find your TCB but before the MD5 check, yes? Since there hasn't been an IOS source code leak in a while, does someone from Cisco who actually knows how this is implemented want to comment so we can stop guessing? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: key change for TCP-MD5
On Jun 23, 2006, at 2:02 PM, Bora Akyol wrote: 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. Unless the DoS is within the IPSEC tunnel and crowds out the good traffic. ; Your original post seemed to imply that IPSEC is an anti-DoS mechanism, as does the statement 'If you pay attention to detail, it does help.' IPSEC is not an anti-DoS mechanism at all, it's important to be clear about that. -- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Everything has been said. But nobody listens. -- Roger Shattuck
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.)
Re: key change for TCP-MD5
On Jun 23, 2006, at 7:17 PM, Iljitsch van Beijnum wrote: 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. Why is this better than using the TTL hack? Which is easier to configure, and at least as secure. -- TTFN, patrick
Re: key change for TCP-MD5
On Thu, 22 Jun 2006 13:18:35 -0400, Ron Bonica [EMAIL PROTECTED] wrote: Steve, In Section 1 of your draft, you say: The proper solution involves some sort of key management protocol. Apart from the complexity of such things, RFC 2385 was not written with key changes in mind. In particular, there is no KeyID field in the option, which means that even a key management protocol would run into the same problem. Fortunately, a heuristic permits key change despite this protocol deficiency. Why not correct the protocol deficiency by introducing a new option that includes a KeyID? Wouldn't that approach provide a more comprehensive solution to the problem? That's a much better long-term strategy, though the exact mechanism still has to be defined. But it's literally years before that will be usable, especially because both ends of a connection need to be upgraded before it delivers any benefits. That is especially problematic for the interISP case. We both agree that key change is (a) necessary, and (b) very difficult with 2385. The longer-term issue is where there his, and that's what your draft addresses; my draft is about how to get from here to there. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: key change for TCP-MD5
On 22-jun-2006, at 23:17, Steven M. Bellovin wrote: Why not correct the protocol deficiency by introducing a new option that includes a KeyID? Wouldn't that approach provide a more comprehensive solution to the problem? That's a much better long-term strategy, though the exact mechanism still has to be defined. But it's literally years before that will be usable, especially because both ends of a connection need to be upgraded before it delivers any benefits. If you want benefits when only one end is upgraded, your mechanism for concurrent keys could be used like this: - the upgraded side installs the new key - the upgraded side keeps using the old key - the non-upgraded side installs the new key - the upgraded side detects that the other side uses the new key and switches over itself - the old key is removed from the upgraded side This way, it all goes down when the non-upgraded side installs the key: they can immediately see the problem if there is some kind of issue with the key (for instance someone entered it incorrectly). It still makes sense to add stuff that allows both ends to manage the key rollover when they're both upgraded, since in that case something like the above won't work. I think something like this would work well: - announce key rollover capability at session connect - when a new key is configured, send a hash of it to the other side - other side doesn't have the key yet so says reject - other side is also configured with the new key, sends a hash - first side sees hashes match, starts sending with the new key and says accept Bonus points: when no key is configured, one of the routers generates one at session start and sends it over in the clear. This protects equally well against session reset attacks as a preconfigured key, but obviously it can be sniffed by someone with access to the infrastructure. We both agree that key change is (a) necessary, and (b) very difficult with 2385. How often do you think keys should change? I've never had anyone ask to change keys for about 50 session-years.
RE: key change for TCP-MD5
How often do you think keys should change? Arguably, any time someone who had access to the key is no longer supposed to have such access. I've never had anyone ask to change keys for about 50 session-years. I guess the question the question is whether that's because they really never needed to, really didn't think about, or really didn't want to suffer the hassle and so just accepted the risk. DS
Re: key change for TCP-MD5
On Tue, Jun 20, 2006 at 05:18:20PM -0700, Randy Bush wrote: 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). gstm this doesn't help if the vendor can't implement it correctly and does the md5 calc before checking the ttl :( - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: key change for TCP-MD5
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). gstm this doesn't help if the vendor can't implement it correctly and does the md5 calc before checking the ttl :( hard to imagine anything that will help such a vendor randy
RE: key change for TCP-MD5
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
Re: key change for TCP-MD5
At 07:29 PM 6/20/2006 -0400, Richard A Steenbergen wrote: On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote: ...I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist I think that it does make sense to be clear what attack or set of attacks we are trying to protect against. One type of attack is the TCP reset attack. I personally don't have a strong opinion regarding whether it is worth protecting against only this attack. 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
RE: key change for TCP-MD5
All the multiple keys do is to decrease the cost of the DOS. Yes let's try to remember that, in reality, this is all about allowing two bgp peers to move to a new key without having the operators on the phone to keep the bgp session from resetting. i.e., o it will be uncommon that there is more than one key active at any one time o it is not expected that there are more than two, current and new (soon to be current and old:-) active at any one time smb is proposing a simple, compatible, unilaterally implementable, and unilaterally deployable hack to solve a real ops problem. the RSs aside, a lot of very big and small networks use tcp/md5 on their bgp sessions, and key roll is a major pita and therefore a serious barrier to good key hygiene. randy
Re: key change for TCP-MD5
--- Ross Callon [EMAIL PROTECTED] wrote: 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. But it's safe to say that it would be a lot easier to crack a router itself than to unobtrusively insert useful false information, or if the ISP's routers are sufficiently hardened, it would be easier to crack a customer (or peer)'s router, and use that for the injection. The same mechanisa which can detect bogus prefixes from a peer/customer can detect them from a hijacked session. The cost/benefit ratio is better for securing the routers themselves. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: key change for TCP-MD5
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
RE: key change for TCP-MD5
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 ;) this is the you don't have to run faster than the lion, you just have to run faster than your friend, theory. as those who survived to report are a biased sample, it is not well tested. black hats are opportunistic, but not lazy. they look for cracks with mamzing diligence. e.g the recent brilliant post on cracking the xbox http://www.xbox-linux.org/wiki/17_Mistakes_Microsoft_Made_in_the_Xbox_Security_System. when low-hanging fruit is unavailable, or when they see a really cool way to exploit the higher fruit, it would be prudent to have done something about it. who cares about openly recursive dns servers? there are easier ways to crack the host. oops! unfortunately, this is not just theory. few talk about the serious routing attacks that have been seen. randy
Re: key change for TCP-MD5
On Wed, Jun 21, 2006 at 05:55:21PM -0700, Randy Bush wrote: when low-hanging fruit is unavailable, or when they see a really cool way to exploit the higher fruit, it would be prudent to have done something about it. who cares about openly recursive dns servers? there are easier ways to crack the host. oops! There is a fine line between being dilligent about security, and wasting your time trying to solve problems that don't exist, which I think has been crossed in the discussion. Not to venture too far away from facts and into the realm of cute soundbites and quotable one-liners about lions and fruit, but let me propose what I think is a good one: If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. I have yet to hear a reasonable counter-argument to this. If there is one out there that had not yet been made then by all means now is the time to make it. Otherwise, you would really be better served by devoting your time and energy into solving real problems. If you're running low on real problems to solve, I would be happy to send you some of mine. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: key change for TCP-MD5
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. 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. Regards Bora -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.
Re: key change for TCP-MD5
On 20-jun-2006, at 21:12, 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. No time synchronization required. No BGP message required. What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet?
RE: key change for TCP-MD5
The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key once
Re: key change for TCP-MD5
What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet? again: try reading the draft
Re: key change for TCP-MD5
On 20-jun-2006, at 21:23, Randy Bush wrote: What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet? again: try reading the draft I've read the draft and it solves this problem with timing. That's insufficient because it requires that both sides do the right thing at the right time without any way to verify whether the other side is ready. What if one side didn't make the change, or entered the wrong key? I think I've sufficiently explained myself now, I'm not going to do it again.
Re: key change for TCP-MD5
On Tue, 20 Jun 2006 21:16:05 +0200, Iljitsch van Beijnum said: What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet? How is that *any* different than you sending an e-mail saying Here's the new key we'll put into production at 3:17:04.97 GMT, hope you're NTP-synced and not waiting for an ACK from the other end before proceeding? I'd encourage my competitors to design their procedures that way, but it only works for competitors that you aren't either peering or directly transiting with. Otherwise, you're merely handing them a loaded gun to point at your feet... pgpzFWcU74ccf.pgp Description: PGP signature
Re: key change for TCP-MD5
On 6/20/2006 at 12:33 PM, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 20-jun-2006, at 21:23, Randy Bush wrote: What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet? again: try reading the draft I've read the draft and it solves this problem with timing. That's insufficient because it requires that both sides do the right thing at the right time without any way to verify whether the other side is ready. What if one side didn't make the change, or entered the wrong key? Uh, isn't what this, In particular, if a key change has just been attempted but such segments are not acknowledged, it is reasonable to fall back to the previous key and issue an alert of some sort. Is for? Automated fallback if a new key doesn't work? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
RE: key change for TCP-MD5
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.
RE: key change for TCP-MD5
Good comments, please see inline: -Original Message- From: Ross Callon [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 2:06 PM To: Bora Akyol; nanog@merit.edu Subject: RE: key change for TCP-MD5 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. Ross The DOS is a concern whether you have a valid key or not, correct? I can DOS the router with fake packets that it needs to verify as long as I want. All the multiple keys do is to decrease the cost of the DOS. 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. For device vendors, they need to solve this problem regardless of the number of simultaneous key checks. For example, they can use a TCP-offload-engine for their CPU. The TOE engines are being used in servers for a long time now. 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. 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 Please see my comments above. Regards Bora
Re: key change for TCP-MD5
On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote: 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. I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist. After that, I'd like them to explain why we need to devote more resources to protecting against the attack that already doesn't exist, and that is already protected against just fine even if it were to exist. Of course any not completely insane implementation should be checking for a valid TCP window range (or an existing TCB for that matter) before wasting CPU time on an MD5 calculation. It's just not possible in reality for any sufficiently large number of packets to get through those check to then be affected by an MD5 DoS (unless of course you're peering with 7018, and the NSA has an extra copy of your packets laying around). We already collectively wasted our time deploying MD5 passwords over a big scare that turned out to be nothing more than someone cracking open the manual and rediscovering how stuff worked all along. Why don't we spend our time going forward solving actual issues like filtering/announcement authentication, and stop trying to solve the non-existant problems. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: key change for TCP-MD5
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). gstm
Re: key change for TCP-MD5
On Jun 20, 2006, at 4:29 PM, Richard A Steenbergen wrote: We already collectively wasted our time deploying MD5 passwords over a big scare that turned out to be nothing more than someone cracking open the manual and rediscovering how stuff worked all along Bwahahahhahaha. I work with that someone --- he (and the rest of his group) are wildly proud of this l33t discovery W . Why don't we spend our time going forward solving actual issues like filtering/ announcement authentication, and stop trying to solve the non-existant problems. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e- gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien
Re: key change for TCP-MD5
I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist. because the non-existent attack(s) have occurred. and keys have been compomised. randy
Re: key change for TCP-MD5
Steven M. Bellovin wrote: I just submitted an I-D on TCP-MD5 key change. Until it shows up in the official repository, see http://www.cs.columbia.edu/~smb/papers/draft-bellovin-keyroll2385-00.txt Here's the abstract: The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. Comments welcome. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb This I-D says BGP implementations should be able to be configured with multiple keys for peers and should do the Intelligent Thing with them. Makes sense to me. Did I read it right?
Re: key change for TCP-MD5
On 19-jun-2006, at 14:32, Steven M. Bellovin wrote: I just submitted an I-D on TCP-MD5 key change. Until it shows up in the official repository, see http://www.cs.columbia.edu/~smb/papers/draft-bellovin- keyroll2385-00.txt Here's the abstract: The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. Comments welcome. I wonder how long that policy will hold. (-: Ok: First of all, I applaud this effort. There doesn't really seem to be a way to introduce a new key other than to just to agree on a time. I'm not sure this is good enough. Wouldn't it be better to exchange some kind of time to change keys message? This could simply be a new type of BGP message that hold a key ID. Obviously the capability to send and receive these messages must be negotiated when the session is created, but still, I think the extra complexity is worth it because it allows for much more robust operation. And is NANOG now officially an IETF working group...? Iljitsch
Re: key change for TCP-MD5
On Mon, 19 Jun 2006 08:59:45 -0400, Joe Maimon [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: I just submitted an I-D on TCP-MD5 key change. Until it shows up in the official repository, see http://www.cs.columbia.edu/~smb/papers/draft-bellovin-keyroll2385-00.txt Here's the abstract: The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. Comments welcome. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb This I-D says BGP implementations should be able to be configured with multiple keys for peers and should do the Intelligent Thing with them. Makes sense to me. Did I read it right? Yes. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: key change for TCP-MD5
On Mon, Jun 19, 2006 at 03:40:50PM +0200, Iljitsch van Beijnum wrote: On 19-jun-2006, at 14:32, Steven M. Bellovin wrote: I just submitted an I-D on TCP-MD5 key change. Until it shows up in the official repository, see http://www.cs.columbia.edu/~smb/papers/draft-bellovin- keyroll2385-00.txt Here's the abstract: The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. Comments welcome. I wonder how long that policy will hold. (-: Ok: First of all, I applaud this effort. There doesn't really seem to be a way to introduce a new key other than to just to agree on a time. I'm not sure this is good enough. I think there is a challenge in making sure the clocks are synced. Wouldn't it be better to exchange some kind of time to change keys message? This could simply be a new type of BGP message that hold a I think there is a challenge in getting the kernel to change keys after getting an underlying message, and the effect this has on your config. Why would you trust their message? Preconfigured keys seem to be the best way. Allowing the kernel to check against a few different keys, or knowing when to 'switch' seems to be the best method IMHO. Ideally it'd use a set of keys in all cases, including the overlap time period +/- a few seconds to avoid dropping the TCP session. key ID. Obviously the capability to send and receive these messages must be negotiated when the session is created, but still, I think the extra complexity is worth it because it allows for much more robust operation. sure, i agree as well. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: key change for TCP-MD5
On Mon, 19 Jun 2006 15:40:50 +0200, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 19-jun-2006, at 14:32, Steven M. Bellovin wrote: I just submitted an I-D on TCP-MD5 key change. Until it shows up in the official repository, see http://www.cs.columbia.edu/~smb/papers/draft-bellovin- keyroll2385-00.txt Here's the abstract: The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. Comments welcome. I wonder how long that policy will hold. (-: I'm not certain what you mean by that, but since it sounds insulting to someone I'll ignore it. First of all, I applaud this effort. There doesn't really seem to be a way to introduce a new key other than to just to agree on a time. I'm not sure this is good enough. Wouldn't it be better to exchange some kind of time to change keys message? This could simply be a new type of BGP message that hold a key ID. Obviously the capability to send and receive these messages must be negotiated when the session is created, but still, I think the extra complexity is worth it because it allows for much more robust operation. There are lots of good solutions if you're willing to change or introduce protocols. That takes a lot longer, both procedurally and technically. This scheme is simple and single-ended, and can be implemented without co-ordination. We should indeed try for a better solution. Until then, I'm suggesting this -- I'm aiming at Informational -- to tide us over. The need for some such solution was quite clear during Bonica's talk in San Jose. And is NANOG now officially an IETF working group...? First, this is draft-bellovin-..., not draft-ietf-..., i.e., an individual submission rather than part of a working group. Second, I'm no longer Security AD. Third, even if this were an official IETF effort by the Security AD, it would be rather stupid not to ask the opinion of the people most directly affected by it. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: key change for TCP-MD5
There doesn't really seem to be a way to introduce a new key other than to just to agree on a time. I'm not sure this is good enough. try reading more carefully
Re: key change for TCP-MD5
On 19-jun-2006, at 16:18, Steven M. Bellovin wrote: Comments welcome. I wonder how long that policy will hold. (-: I'm not certain what you mean by that, but since it sounds insulting to someone I'll ignore it. I see that my attempts at levity (this one by referring to the infamous S/N ratio or the NANOG list) fell on unreachable ports. (Oh no! I just did it again...) Wouldn't it be better to exchange some kind of time to change keys message? This could simply be a new type of BGP message that hold a key ID. Obviously the capability to send and receive these messages must be negotiated when the session is created, but still, I think the extra complexity is worth it because it allows for much more robust operation. There are lots of good solutions if you're willing to change or introduce protocols. That takes a lot longer, both procedurally and technically. This scheme is simple and single-ended, and can be implemented without co-ordination. I'm not sure if you're referring to implementation or operation. But that's not important: a good solution can just as easily be implemented unilaterally, that's what all the option stuff in BGP is for, allowing us to still run BGP4 13 years after its inception, surviving IP version number changes and more. It can't be operationally be implemented without coordination, and that's exactly the problem. Your solution is to agree on a time when the key rollover takes place and then build in a safety margin and optionally, allow senders to return to a previous key if the change is unsuccessful. The problem with this is that the risk that something goes wrong is way too big: if my implementation doesn't support returning to the original key, or doesn't do this fast enough, then very bad things happen as soon as I agree with another AS to change keys at a certain time, and the other side doesn't add the new key to the router in time. I really don't see how saving a little time to market here makes sense, especially since we're not talking about the lid of the cookie jar but about the protocol that holds the internet together, and because the extra effort to do things right seems very modest. We should indeed try for a better solution. Until then, I'm suggesting this -- I'm aiming at Informational -- to tide us over. One thing I don't think many IETFers get is that EVERY change, no matter how small, is a HUGE deal: you need to start a project, get people, write the software, do testing, testing, more testing, write documentation and then do some REAL testing, write some more documentation, train people, send out the software, fix at least some of the bugs that have been found by now... Compared to all the effort that goes in to touching the code period, implementing a little more stuff while you're at it is of little consequence. Especially if you compare it with having to go back later because the extra stuff needs to be implemented anyway. Doing it rightaway saves you another cycle for all the other stuff. On top of this general observation, I also think you're underestimating the amount of work required to implement your draft. Obviously the RFC 2385 code needs to be changed, but don't forget that there must be a way to specify additional keys and the times they become active in the configuration. That's two things that need to be done anyway, doing a third one by adding options to the BGP protocol, doesn't seem like a show stopper to me. The need for some such solution was quite clear during Bonica's talk in San Jose. Maybe. I haven't seen/heard the talk. But I can tell you one thing: operators won't be in a hurry to use the mechanism you suggest for two reasons: even though changing keys is easier this way, it's still not super simple (need to talk to the other side to find out if they support the mechanism and coordinate a password (some people have a hard time grokking GPG/PGP...) and a rollover time), and, more importantly: the change happens at some later point when you're not watching. That's NOT good. No feedback except failure isn't good either. If you really need to change a key you can always call, agree on a new password and count down to three and hit the return key at the same time... You may want to check and see how many people use GTSM/RFC3682 (anyone?). It suffers from the same problem as RFC 2385 and (to a large degree) your proposal: there is nothing wrong with the mechanism per se, but it has to be enabled/configured out of band because there is no negotiation in BGP for using / not using the mechanism.
Re: key change for TCP-MD5
On 19-jun-2006, at 16:54, Randy Bush wrote: There doesn't really seem to be a way to introduce a new key other than to just to agree on a time. I'm not sure this is good enough. try reading more carefully Didn't help...
Re: key change for TCP-MD5
There doesn't really seem to be a way to introduce a new key other than to just to agree on a time. I'm not sure this is good enough. 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. randy
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.
Re: key change for TCP-MD5
IvB Date: Mon, 19 Jun 2006 15:40:50 +0200 IvB From: Iljitsch van Beijnum IvB And is NANOG now officially an IETF working group...? More interaction between IETF and NANOG is good. Kudos to SMB for trying to inspire more of it. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
