ietf
[Top] [All Lists]

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

2012-11-19 10:08:16

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
mjethanandani(_at_)gmail(_dot_)com



<Prev in Thread] Current Thread [Next in Thread>