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