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