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
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?
On Mon, 19 Jun 2006 08:59:45 -0400, Joe Maimon <jmaimon@ttec.com> 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
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
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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Mon, 19 Jun 2006 15:40:50 +0200, Iljitsch van Beijnum <iljitsch@muada.com> 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
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.
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
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.
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: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
participants (6)
-
Edward B. DREGER -
Iljitsch van Beijnum -
Jared Mauch -
Joe Maimon -
Randy Bush -
Steven M. Bellovin