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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Jun 2006 11:40:05 +0200

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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 

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

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 06 Jun 2006 11:55:41 +0100

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:
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>>>   
>>
>>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 7 Jun 2006 11:27:32 -0400

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:[email-masked]] 
Sent: Tuesday, June 06, 2006 6:56 AM
To: Brian E Carpenter
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Gen-art] Re: Partial review of
draft-ietf-v6ops-security-overview-04.txt

Indeed.

/Elwyn

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

>>> 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.
>>>
>>> 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.
>>>   
>>
>>> 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?
>>>   
>>
>>> 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.
>>>   
>>
>> [email-masked] https://www1.ietf.org/mailman/listinfo/gen-art
>>