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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 <jmh@xxxxxxxxxxxxxxx> 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

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
karp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/karp


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]