Re: [Gen-art] Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt

[Mahesh Jethanandani <[e-mail]>]

On Nov 14, 2012, at 3:39 PM, Ben Campbell wrote:

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

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


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

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.

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

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.

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

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. 

> 
> *** Nits/editorial comments ***:
> 
> -- 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 "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.

Done.

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

Done.

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

Done.

> 
> -- section 1, 2nd to last paragraph: "current state of security method"
> 
> Missing article before "security method".

Done.

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

Done.

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

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

> 
> -- section 2.3.1.2, 1st paragraph: "As stated above..."
> 
> A section reference would be helpful.

Done.

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

Changed it to say:

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

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

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

> 

Mahesh Jethanandani
[e-mail]