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

[Elwyn Davies <[e-mail]>]

Indeed.

Sharon: If you have time to finish your review I will hopefully be 
making some updates before leaving on holiday next week.

I am waiting for Russ Housley's comments which were promised this week 
before setting about some changes.

/Elwyn

Brian E Carpenter wrote:
> 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