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 betweentcp/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