Subject: Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Dec 2012 14:14:49 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-karp-routing-tcp-analysis-07
Reviewer: Ben Campbell
Review Date: 2012-12-18
IESG Telechat date: 2012-12-20

Summary: Ready for publication as an informational RFC. There are still a couple of nits that might be worth consideration prior to final publication.

Note: This review is incremental to my review of version 05 at last call. All of my comments in that review have been resolved except as described in this message.

** Major issues:

None

** Minor issues:

None

** Nits/editorial comments:

-- The 2119 paragraph was removed, but there's still an orphaned 2119 entry in the informational reference section.

-- There's a new IANA considerations section. However, I suggest it contain a full sentence to the effect of "This document makes no requests of IANA" rather than simply "None".  (OTOH, this may get removed before final publication anyway...)

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Dec 2012 22:12:38 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 Dec 2012 17:26:11 -0500

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Dec 2012 16:50:08 -0600

I think Nick's email was a review of the document in general, rather than commentary on my review in particular. But since it was addressed to me, I do have one comment in response:

> "MUST" (or even "SHOULD").

I don't think so. This draft does not establish a standard, or define a protocol. While I don't speak for the authors, I don't think it's intended to make normative statements about anything. The language is descriptive, not prescriptive.

(I agree "has to" is an awkward substitute for the non-normative "must". I agree that "must" should generally be avoided when there can be confusion about the normativeness of a statement. I'm not sure that's the case here, since the whole doc is non-normative. And I think we could find better language even when the confusion is possible.)

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Dec 2012 22:26:25 +0000

On 18/12/2012 22:50, Ben Campbell wrote:
> I think Nick's email was a review of the document in general, 

yes, sorry, it was.  I hit reply when I saw the subject line.

> I don't think so. This draft does not establish a standard, or define a
> protocol. While I don't speak for the authors, I don't think it's
> intended to make normative statements about anything. The language is
> descriptive, not prescriptive.

ok, noted.

> (I agree "has to" is an awkward substitute for the non-normative "must".
> I agree that "must" should generally be avoided when there can be
> confusion about the normativeness of a statement. I'm not sure that's
> the case here, since the whole doc is non-normative. And I think we
> could find better language even when the confusion is possible.)

"needs to"?  "ought to"?  It's all massively context dependent though.
What's needed are some words / phrases which are defined to have local
imperative scope only or else nonlocal informative "must" - but yeah it's
messy and generally will involve nontrivial wordsmithing to work around
what is meant.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Dec 2012 23:14:11 +0000

On 18/12/2012 22:26, Joel M. Halpern wrote:
> 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:

>> operational reality it's still the only show in town (no-one uses ipsec for

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.

>> 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.

>> 6192 in the context of providing a link to what other steps might be useful

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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Dec 2012 23:20:49 +0000

On 18/12/2012 23:15, Anantha Ramaiah wrote:
> Also TCP MD5 with periodic key rollover can make the life harder for TCP
> MD5 based collision attacks.

there is no facility in rfc 2385 for automatic key rollover, which means
that any key changes must be done manually.  I've come across gratuitous
key rollover happening exactly once in my career: namely where (as far as I
understand) a particular company had used the same MD5 key for all ebgp
peering sessions worldwide.  They eventually decided that this wasn't such
a good idea and subsequently changed keys whenever they changed routers /
bgp sessions / did port upgrades / etc.  Other than that, I've never come
across a case of someone wanting to proactively change a session key
because it seemed to be a good idea.  Just sayin'.

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Dec 2012 09:16:54 -0500

Thank you Nick.
With regard to the suggest text replacement of "has to" with "needs to", 
if you think that will help, lets go wit it (at then let the RFC Editor 
tell us if it doesn't work.)

With regard to obsoleting TCP-MD5, that is what the RFCs say.  The 
TCP-MD5 is obsoleted by the TCP-AO RFC.  Further, the security folks are 
quite adamant that we should be shifting our recommendations, and where 
possible our practice.  If there are not yep implementations, we need to 
be pushing folks harder to get them.

If I understand your next item properly, you are asking that we add a 
sentence about the fact that implementation of security mechanisms needs 
to be doe carefully, so as not to make things worse.  Seems easy to do 
and can't hurt, so we should do so.

And equally, noting that security is more than cryptography, and more 
than signatures, is probably sensible.

Authors, WG, can we live with these?  I would think so.

Yours,
Joel

---

From: Anantha Ramaiah <[email-masked]>
Date: Tue, 18 Dec 2012 15:15:41 -0800

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 <[email-masked]>wrote:

> 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
>
>>> -- The 2119 paragraph was removed, but there's still an orphaned 2119
>>> entry in the informational reference section.
>>>
>>
>> -   [draft-zheng-mpls-ldp-hello-**crypto-auth-04] suggest a new
>> +   [draft-zheng-mpls-ldp-hello-**crypto-auth-04] suggests a new
>>
>> --
>>
>>  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>
>>>
>>
>>  ______________________________**_________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/karp<https://www.ietf.org/mailman/listinfo/karp>
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 20 Dec 2012 07:42:24 -0800

Yes.

> Authors, WG, can we live with these?  I would think so.

Mahesh Jethanandani
[email-masked]