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

["Sharon Chisholm" <[e-mail]>]

hi

I've completed my review and only managed to find a few more minor nits:

7. In section 2.4, it seems there are two typos: accpetable and
mecahnism .

8. In section 3.3, the term SOHO is used but not explained. I'm guessing
it Small Office/Home Office after a bit of googling.

9. In appendix B, first paragraph it says "The generation of IPv6
addresses of IPv6 addresses from MAC addresses" while I imagine it
should read "The generation of IPv6 addresses from MAC addresses"

Sharon

-----Original Message-----
From: Elwyn Davies [mailto:[e-mail]] 
Sent: Tuesday, June 06, 2006 6:56 AM
To: Brian E Carpenter
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: [Gen-art] Re: Partial review of
draft-ietf-v6ops-security-overview-04.txt


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-overvi
>>> ew-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