Subject: Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Nov 2012 17:39:39 -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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-karp-routing-tcp-analysis-05.txt
Reviewer: Ben Campbell
Review Date: 2012-11-14
IETF LC End Date: 2012-11-19

Summary: This draft is almost ready for publication as an informational RFC. There are a few minor issues and a number of editorial issues that should be considered prior to publication.

*** Major issues ***:

None

*** Minor issues *** :

-- section 2.2, last paragraph:

The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I assume so, but there's been no mention of IPSec so far.

-- section 2.3.2:

It would be helpful for this section to describe whether privacy issues actually matter or not, rather than just stating the issues to be similar to those for other routing protocols.

-- section 3.1, 2nd paragraph:

Does this mean that privacy is really not needed, or just that LDP does not state a requirement for privacy?

-- Section 6 (Security Considerations), 4th paragraph:

If replay protection is required, shouldn't the draft discuss the details somewhere? I see only one mention in passing outside of this section.

*** Nits/editorial comments ***:

-- IDNits indicates some unused and obsoleted references. Please check.

-- The IANA considerations section is missing. If the draft makes requests of IANA, it should include the section and state that.

-- the short title is "The IANA considerations section is missing. If the draft makes requests of IANA, it should include the section and say that

-- The short title is "draft-ietf-karp-routing-tcp-analysis-05.txt". Is this draft in any way specific to TCP? If so, it would be helpful to mention that in the abstract and introduction.

-- Punctuation errors are pervasive, particularly in the early and late sections. These make it harder to read than it needs to be. In particular, I suggest the draft be proofread for missing commas and missing quotes (or other marks) around document titles.

-- Section 1, paragraph 1:

The cited doc name should be quoted, or otherwise marked. Also, it's not necessary to put the full reference here, since you are citing the references section.

-- Section 1, paragraph 1: "Four main steps were identified for that tightening:"

For what tightening? This is the first mention. Perhaps the previous sentence should have gone on to say "... and suggests steps to tighten the infrastructure against the attack"?

-- section 1, 1st paragraph after numbered list:

The end of the paragraph does not seem related to the beginning. I suggest a paragraph split before the sentence starting with "The OPSEC working group..." 

-- section 1, 2nd to last paragraph: "current state of security method"

Missing article before "security method".

-- section 1.1:

Why is 2119 language needed? I see two potentially normative statements--but both of those merely describe the existing MAC requirements in TCP-AO. It would be better to state those in descriptive language (e.g. TCP-AO requires…) and to drop the 2119 section entirely. 

-- section 2.1,  5th paragraph:

A mention of SHA1 seems needed here. Section 2.3.1.2 states the concerns about TCP-md5 more clearly.

-- section 2.3.1.2, 1st paragraph: "As stated above..."

A section reference would be helpful.

-- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to Blind In-Window Attacks."

sentence fragment.

-- section 4, 3rd paragraph:

It would have been helpful to mention the MKT manual config issue back in the "state of the security method" sections.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 18 Nov 2012 23:58:36 -0800

> The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I assume so, but there's been no mention of IPSec so far.

No. It implies the use of IKEv2 protocol for performing mutual authentication and establishing SA. There is no suggestion of using IKE with IPSec.

How about this?

For point-to-point key management IKEv2[RFC5996] protocol provides ...

> It would be helpful for this section to describe whether privacy issues actually matter or not, rather than just stating the issues to be similar to those for other routing protocols.

Changed it to:

Labels, like routing information are distributed in the clear. There is currently no requirement for labels to be encrypted and that work is outside the scope of the KARP working group.

> Does this mean that privacy is really not needed, or just that LDP does not state a requirement for privacy?

Further clarified it in this section.

Labels are similar to routing information which is distributed in the clear. It is important to ensure that routers exchaning labels are mutually authenticated and that there are no rogue peers or unauthenticated peers that can compromise the stability of the network. However, there is currently no requirement that the labels be encrypted.

> If replay protection is required, shouldn't the draft discuss the details somewhere? I see only one mention in passing outside of this section.

I have moved the replay protection requirement to the gap analysis section. 

However, this document is a analysis draft, and it is my understanding that details on what replay protection methods should be adopted, is best left to the routing protocols in question. 

> -- IDNits indicates some unused and obsoleted references. Please check.

Found one unused reference and have removed it.

> -- The IANA considerations section is missing. If the draft makes requests of IANA, it should include the section and state that.

There are no IANA requests. I have gone ahead and added a section on IANA considerations and stated none are requested.

> -- The short title is "draft-ietf-karp-routing-tcp-analysis-05.txt". Is this draft in any way specific to TCP? If so, it would be helpful to mention that in the abstract and introduction.

Done.

> For what tightening? This is the first mention. Perhaps the previous sentence should have gone on to say "... and suggests steps to tighten the infrastructure against the attack"?

Done.

> The end of the paragraph does not seem related to the beginning. I suggest a paragraph split before the sentence starting with "The OPSEC working group..." 

Done.

> Missing article before "security method".

Done.

> Why is 2119 language needed? I see two potentially normative statements--but both of those merely describe the existing MAC requirements in TCP-AO. It would be better to state those in descriptive…

Done.

> A mention of SHA1 seems needed here. Section 2.3.1.2 states the concerns about TCP-md5 more clearly.

The 6th paragraph states the concern and mentions SHA-1. Did you want something more to be included?

> A section reference would be helpful.

Done.

> -- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to Blind In-Window Attacks."

Changed it to say:

In addition, the recommendations in Improving TCP's Robustness to Blind In-Window Attacks

> It would have been helpful to mention the MKT manual config issue back in the "state of the security method" sections.

Good point. Moved the mention to section 2.2 - Keying issue.

Mahesh Jethanandani
[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Nov 2012 17:12:57 -0600

Hi, thanks for the response. I removed sections that didn't seem to need further comment:

On Nov 19, 2012, at 1:58 AM, Mahesh Jethanandani <[email-masked]> wrote:

[...]

> For point-to-point key management IKEv2[RFC5996] protocol provides ...

5996 describes IKEv2 as a component of IPSec, and a key-management mechanism for ESP and AH SAs. Now, I won't claim to be an IKE expert by any extent, but I think that if you mean to use IKE _without_ IPSec it would be good to add a sentence or two pointing that out. Or is there some other reference that could be used that describes using IKEv2 for non-IPSec SAs?

> Labels, like routing information are distributed in the clear. There is currently no requirement for labels to be encrypted and that work is outside the scope of the KARP working group.

WFM

> Labels are similar to routing information which is distributed in the clear. It is important to ensure that routers exchaning labels are mutually authenticated and that there are no rogue peers or…

Okay

> However, this document is a analysis draft, and it is my understanding that details on what replay protection methods should be adopted, is best left to the routing protocols in question. 

That's fine, pointing out the gap is sufficient.

> Found one unused reference and have removed it.

Seems like there were more than one. From IDNits:

  == Missing Reference: 'IRR' is mentioned on line 92, but not defined

  == Unused Reference: 'RFC2409' is defined on line 585, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3547' is defined on line 588, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

  -- Obsolete informational reference (is this intentional?): RFC 2409
     (Obsoleted by RFC 4306)

  -- Obsolete informational reference (is this intentional?): RFC 3547
     (Obsoleted by RFC 6407)

[...]
> The 6th paragraph states the concern and mentions SHA-1. Did you want something more to be included?

No, sorry, on a re-read I think it's okay.

[...]

> In addition, the recommendations in Improving TCP's Robustness to Blind In-Window Attacks

Am I correct in assuming this merges with the following sentence? Otherwise, it's still a fragment.

[...]

Thanks!

Ben.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 25 Nov 2012 17:56:39 -0800

Further trimming it to sections that require a response.

> 5996 describes IKEv2 as a component of IPSec, and a key-management mechanism for ESP and AH SAs. Now, I won't claim to be an IKE expert by any extent, but I think that if you mean to use IKE _witho…

Added this sentence.

Although IKEv2 is discussed as a component of IPsec, KMP can use just the mutual authentication and SA establishment portion of IKEv2.

>  -- Obsolete informational reference (is this intentional?): RFC 3547

I have removed these unused references.

Changed it to:

In addition, the recommendations in RFC 5961 should also be followed ...

Mahesh Jethanandani
[email-masked]