[Gen-art] Re: Partial review of draft-ietf-v6ops-security-overview-04.txt

Sharon Chisholm wrote:
> Attached is my review of the specified document, submitted as part of
> the Gen-ART process.  For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Document:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-0
> 4.txt
>
> Summary: This draft is basically ready for publication, but has nits
> that
> 	should be fixed before publication.
>
> Comments:
>
> I somehow wasn't paying attention and only realized at the last minute
> that I was assigned this review for today's meeting. Apologies for the
> lateness and incompleteness of this review. I only managed to review to
> the end of section 2.3.
>
> 1. In section 1, second paragraph, it says "It is important to
> understand that we have to be concerned not about replacing IPv4 with
> IPv6", which seems a bit bold of a statement without a clarification
> like "in the near future" or some form of explanation.
>   
The sentence is intended to mean that we aren't going to see the 
all-IPv4 net going away to be replaced by the all-IPv6 network (in the 
short term - actually that is an understatement- more like the long 
teerm). Instead we have to deal with co-existence for a very long time.

Maybe the words could be improved.

> 2. In section 2.1.1, second paragraph and after the bullets, there is a
> typo - "point wher it is being "
>
> 3. The document contains a number of references to internet drafts that
> originally defined the problems discussed. The document claims "Several
> of these issues have been discussed in separate drafts but are
> summarized here to avoid normative references that may not become RFCs",
> but it isn't clear what the RFC editor should do. Should it delete all
> these references or just delete the ones that are not RFCs at the time
> of publication, or should it evaluate which it thinks will someday
> become RFCs and then wait for them?
>   
I believe that it is OK to leave the references as 'work in progress' 
since they are informative in an Informational document.
> 4. Section 2.1.9. 1 does not make a recommendation. Are we suggesting
> that middleware boxes should inspect these packets or just letting
> people know about the conflict. A recommendation of some sort would seem
> more satisfying.
>   
Yes it would... unfortunately this is difficult because doing what is 
advisable breaks the letter of the IPv6 standard and doing what the 
standard says can lead to a security hole.  IMO the standard should be 
fixed but that is not something we can recommend or expect here- so we 
can point out that you can do it and leave it to operators to do as they 
see fit.  Recommending either way would be to upset somebody.
> 5. In section 2.1.9.2, third paragraph says that "This either limits the
> security that can be applied in firewalls or makes it difficult to
> deploy new extension header types", but I did not find information in
> this section to support that conclusion. It may well be true, but it
> isn't supported. Why is it difficult to skip over header extensions I
> don't recognize, for example?
>   
Because there is no guarantee that a random new header is in the right 
TLV format.  It alsmost certainly would be but the standard doesn't 
*guarantee* it.  Again this ought to be fixed.
> 6. In section 2.3.2, second paragraph, second bullet, isn't it mandatory
> to implement ipsec in IPv6 but it isn't mandatory to deploy it is it?
> I'm not sure this distinction is clear in this bullet. (Assuming my
> understanding is correct that is) 
>
>   
A conforming implementation has to implement it - and hence it *should* 
be deployed.  The choice is whether the user chooses to use it for any 
given session.  I think the statements in the section are correct.

Regards,
Elwyn
> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
>   

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art