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

[Nick Hilliard <[e-mail]>]

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