Re: Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

["Joel M. Halpern" <[e-mail]>]

Thank you Nick.
With regard to the suggest text replacement of "has to" with "needs to", 
if you think that will help, lets go wit it (at then let the RFC Editor 
tell us if it doesn't work.)

With regard to obsoleting TCP-MD5, that is what the RFCs say.  The 
TCP-MD5 is obsoleted by the TCP-AO RFC.  Further, the security folks are 
quite adamant that we should be shifting our recommendations, and where 
possible our practice.  If there are not yep implementations, we need to 
be pushing folks harder to get them.

If I understand your next item properly, you are asking that we add a 
sentence about the fact that implementation of security mechanisms needs 
to be doe carefully, so as not to make things worse.  Seems easy to do 
and can't hurt, so we should do so.

And equally, noting that security is more than cryptography, and more 
than signatures, is probably sensible.

Authors, WG, can we live with these?  I would think so.

Yours,
Joel

On 12/19/2012 6:14 PM, Nick Hilliard wrote:
> 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
>
>