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

[Brian E Carpenter <[e-mail]>]

Actually this got deferred by one telechat, so maybe Sharon has the
chance to look at the rest...

I will very likely be a No Objection, this being a draft I have kept
an eye on; it would be rather hypocritical to Discuss it at this
late stage. Since there are a couple of quite tricky Discuss comments,
there well may be a revision coming, at which point I trust the authors
will review Sharon's comments.

    Brian

Elwyn Davies wrote:
> 
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art