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

[Anantha Ramaiah <[e-mail]>]

FWIW,
      I have to agree with Nick's observations w.r.t TCP MD5. Especially
the following :-

- TCP MD5 is not universally turned on to protect LDP sessions. It is case
by case. TCP MD5 is better than no security at all. Also TCP MD5 with
periodic key rollover can make the life harder for TCP MD5 based collision
attacks. It is better than TCP-MD5 with no key rollover.

(so, you see the degree of protection varies and the Nick's example of 5
pin versus 7 pin barrel lock, which I like :-)

- I also agree that there are no live TCP-AO implementations to date.
TCP-MD5 on the other hand has been there and still there in many vendors
TCP stacks.

I think it is a good idea to note some the points (esp the CPU utilization
depending on the crypto algorithm of choice etc.,) into the draft. Makes
sense to me.

thanks,
-Anantha


On Tue, Dec 18, 2012 at 2:26 PM, Joel M. Halpern <[e-mail]>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.
>
> 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?
>
> Thank you,
> Joel
>
> On 12/18/2012 5:12 PM, Nick Hilliard wrote:
>
>> On 18/12/2012 20:14, Ben Campbell wrote:
>>
>>> ** Nits/editorial comments:
>>>
>>> -- The 2119 paragraph was removed, but there's still an orphaned 2119
>>> entry in the informational reference section.
>>>
>>
>> I'm not sure that this was a good idea.  There are a lot of "has to"s in
>> this text, and it's not clear to me whether they are phrased like that as
>> a
>> way of getting around 2119, or what's going on.  Whatever the reason, "has
>> to" sounds very informal and probably not suitable for a document like
>> this.  Could we have some clarification as to why "has to" doesn't mean
>> "MUST" (or even "SHOULD").
>>
>> --
>>
>> -   protocol stack from CPU-utilization based attacks.TCP Robustness
>> +   protocol stack from CPU-utilization based attacks. TCP Robustness
>>
>> --
>>
>> 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).
>>
>> Secondly, as a general comment about the TCP MD5 option, no-one that I
>> know
>> uses it as a serious security mechanism, but instead as a means of putting
>> the equivalent of a padlock on the barn door.  This does two things: 1. it
>> stops bgp sessions from being accidentally re-used (e.g. at IXPs or on
>> commercial providers who are re-using access ports), and 2. it simply
>> raises the bar in terms of difficulty.  If your barnyard door has a
>> padlock, and the one beside doesn't, the average lazy human being will
>> attempt to poke at the one which doesn't.
>>
>>  From an operational view, i would generally see the difference between
>>>
>> tcp/md5 and tcp/sha1 (via tcp-ao) as being similar to the difference
>> between a 5 pin and a 7 pin barrel lock.  Both look like a lock on the
>> outside, and the thief is probably going to smash a window to get in
>> anyway, or look for the key which the owners left under the mat.
>>
>> --
>>
>> 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.
>>
>> I don't know whether these things should be noted in the draft.
>>
>> --
>>
>> 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.
>>
>> --
>>
>>      pairs of routers when using TCP MD5.  It is well known that the
>>>     longer the same key is used, the greater the chance that it can be
>>>     guessed or exposed
>>>
>>
>> I'm split between {{cn}} and [[Wikipedia:OBVIOUS]].  Hmmm, life's little
>> decisions.
>>
>> --
>>
>>      Routers lack comprehensive key management and keys derived from it
>>>     that they can use to authenticate data.
>>>
>>
>> clumsy wording (and grammatically incorrect).
>>
>> --
>>
>>      Authentication, tamper protection, and encryption all require the use
>>>
>>
>> should that second comma be dropped?  Not sure what the ietf style
>> dictates.
>>
>> --
>>
>>      Authentication, tamper protection, and encryption all require the use
>>>     of keys by sender and receiver.  An automated KMP therefore has to
>>>     include a way to distribute MKT between two end points with little or
>>>     no administration overhead.  It has to cover automatic key rollover.
>>>
>>
>> "has to" has to become "MUST", shouldn't it?
>>
>> Also, the third sentence is a semantic repeat of the second - and much
>> easier to understand, too.
>>
>> --
>>
>> -    that, where PCEs are discovered and not configured, the PCC cannot
>> +    that where PCEs are discovered and not configured, the PCC cannot
>>
>> --
>>
>> -   [draft-zheng-mpls-ldp-hello-**crypto-auth-04] suggest a new
>> +   [draft-zheng-mpls-ldp-hello-**crypto-auth-04] suggests a new
>>
>> --
>>
>>               An LSR can reduce the threat of spoofed Extended Hellos by
>>>     filtering them and accepting Hellos from sources permitted by an
>>>     access lists.
>>>
>>
>> "permitted by an access list".
>>
>> --
>>
>>    However, performing the filtering using access lists
>>>     requires LSR resource, and the LSR is still vulnerable to the IP
>>>     source address spoofing.
>>>
>>
>> This is a little clumsy.  Maybe rephrase as: "However, filtering with
>> access lists requires LSR resources, and the LSR may still be vulnerable
>> to
>> IP source address spoofing."
>>
>> "may" rather than is.  This will depend on the iACL policy of the network.
>>
>> --
>>
>>  Spoofed Hello messages are observed and reported as real
>>>     problem in production networks.
>>>
>>
>> s/problem/problems/
>>
>> {{cn}}
>>
>> --
>>
>>      The Message Authentication Codes (MACs) used by TCP MD5 option, is
>>>     considered too weak
>>>
>>
>> oops, grammar.
>>
>> --
>>
>>  Cryptographic research suggests that both these
>>>     MAC algorithms defined are fairly secure.
>>>
>>
>> Today's "fairly secure" algorithms are tomorrow's swiss cheese:
>>
>>  http://www.eetimes.com/**electronics-news/4051745/**Chinese-researchers-
>>> **compromise-SHA-1-hashing-**algorithm<http://www.eetimes.com/electronics-news/4051745/Chinese-researchers-compromise-SHA-1-hashing-algorithm>
>>>
>>
>> I would explicitly avoid the use of ".* secure", and if the authors feel
>> the need to make any statement about them, that it should be prefixed by
>> woolly, hand-wavey, get-out-of-jail-free phrases, e.g. "at the time of
>> authorship, there are no publicly known attacks on this algorithm which
>> reduce the strength to complexity of less than 1 in X", or however
>> crypto-heads like to phrase that sort of thing.  Right now, that phrase is
>> headed towards algorithmic oblivion.
>>
>> --
>>
>>  LDP [RFC5036] does not provide any security
>>>     mechanisms for use with Hello messages except for some configuration
>>>     which may help protect against bogus discovery events.  These
>>>     configurations include directly connected links and interfaces.
>>>
>>
>> suggest rewording:
>>
>> LDP [RFC5036] does not provide any security mechanisms for use with Hello
>> messages, although operational workarounds may be implemented such as
>> using directly interfaces.
>>
>> --
>>
>> There are possibly more nits in there - I haven't exhaustively gone
>> through
>> all the text, but it needs a good shake-down by a style editor.
>>
>> Otherwise I like this draft and think it has merit as a general
>> informational overview.
>>
>> Nick
>>
>>
>>  ______________________________**_________________
> karp mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/karp<https://www.ietf.org/mailman/listinfo/karp>
>