On 18/12/2012 22:26, Joel M. Halpern wrote: > Nick, I appreciate that you have read this document and commented. > > Two general questions: > 1) Can you be more specific about where you see unclear language usage? It > is hard to fix a general coment. I was referring to the use of "has to", but the phrase only appears three times so maybe it's not going to be a large amount of work to eradicate it. This might work: s/has to/needs to/g I overestimated to myself the number of times it appeared by flicking back and forwards through the document when looking at it last night. > 2) A number of your comments seem to be about general router security. Many > of them would see far more appicable to RFC 6518. This document is just > about changes to protect TCP sessions (yes, what we are concerned about are > the TCP sessions used by routers.) Can you take a look at your comments, > and tell us which ones are applicable to this document, and which ones > should be held for when the community is ready to revise RFC 6518? 6518 looks like a roadmap to me. I don't see any of these comments as being especially relevant to that document. There are 3 general suggestions and the rest of the issues are either style or syntax editing issues, and I think they are all relevant to this document. These suggestions are: 1: >> I have a general issue with the statement "TCP MD5 [RFC2385] has been >> obsoleted by TCP-AO [RFC5925]." At this time, I'm not aware of any live >> TCP-AO implementations. So while I understand that md5 is effectively >> obsolete from the specification point of view, from the point of view of >> operational reality it's still the only show in town (no-one uses ipsec for >> this). We don't have running code for the new protocol, but we have very wide deployment for the older protocol. So I question how appropriate it is to make a statement on whether the new protocol has obsoleted the old one. I'm not familiar enough with ietf nous to know whether this is relevant to a document like this. Wearing my operator hat, it looks a little odd, that's all. 2: >> There is a second operational issue which may merit mention here, namely >> the issue of ensuring that whatever session layer authentication is >> implemented on an actual network device, that it doesn't create more >> problems than it solves. Specifically, if session layer authentication is >> pushed too far down the protocol stack, cryptographic authentication can >> occur before other basic checks which might be a whole pile less CPU >> intensive. There was a scare about this several years ago when it turned >> out that a well-known vendor had implemented tcp md5 checksumming before >> more basic tcp session checks (e.g. seq numbers, ttl, etc). In the event, >> this turned out to be a red herring because md5 is sufficiently gentle on >> the CPU that it didn't make much difference in reality. >> >> However, there is cryptographic value in using more computationally >> intensive hashing algorithms, and if routers (which often have relatively >> slow general CPUs or route-processor CPUs) were to get trashed with a large >> flood of packets which were signed with a cpu-intensive hashing algorithm, >> and if the checksum were to be implemented in the wrong place in the TCP >> stack, then this could become an actual problem. Whatever a router manufacturer does in terms of implementation, they need to be careful when writing code to ensure that they don't accidentally open up other attack vectors by implementing transport layer security badly. It almost happened once before, and this could have caused damage at the time if we had had been using a computationally expensive algorithm like openbsd bcrypt instead of md5. 3: >> It may be useful to consider whether to acknowledge the existence of rfc >> 6192 in the context of providing a link to what other steps might be useful >> to secure routers. What I'm suggesting here is a single sentence around the first paragraph in section 2.1 to say that while it's outside the context of transport security, there's more to protecting routers than cryptography - and then provide a link to 6192 as an informative reference to someone who might be interested in the more general area router security. General router security is a large subject which is not particularly pertinent to keying and authentication, but a random operator who happens to read this ID when it's published might appreciate the pointer. Nick