IPv6 Transition/Co-existence Security Considerations
draft-ietf-v6ops-security-overview-06

Gen-ART review comments by Sharon Chisholm, with embedded author
responses on some of them. If there is a revised ID, these points
could be tidied up:

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:elwynd@dial.pipex.com] 
Sent: Tuesday, June 06, 2006 6:56 AM
To: Brian E Carpenter
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; david.kessens@nokia.com;
fred.baker@cisco.com; gen-art@ietf.org; suresh.krishnan@ericsson.com;
kurtis@kurtis.pp.se; psavola@funet.fi
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
>>>> Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
>>>>

I agree with the bulk of the comments people have brought up. However, I don't want the tone to change to there are no problems here. I think the document points out many real and relevant security issues - removing theses would only make it harder to address them an ultimately slow down the deployment. If experts generally agree that X is a viable way to do an certain attack on at least some relevant subset of vendors equipment, I don't think that we need to have a published reference to that problem or a demonstrated case of that attack to consider it a possible threat that the document needs to discuss. If changes get made to the document, please keep that in mind.

1. In Section 2.1.12: 

   These vulnerabilities can be mitigated in several ways.  A general
   solution will require
   o  authenticating the link layer connectivity, for example by using
      IEEE 802.1x functionality, port-based MAC address security
      (locking), or physical security, and

This paragraph leaves the impression (not sure if this is intentional) that port-based MAC address security (locking) can be an alternative of IEEE 802.1X port-based network address control. I believe that this is not true, MAC locking is not a standard and moreover, it is vulnerable to spoofing. I suggest to take out this and leave only the reference to IEEE 802.1X and physical security.

Also, it would be worth writing 802.1X with a 'capital X' which has a significance in the IEEE 802 alphabet soup. Adding a proper Informative Reference would also be useful: 

[IEEE-802.1X]
          IEEE Standards for Local and Metropolitan Area Networks: Port
          based Network Access Control, IEEE Std 802.1X-2004,  December
          2004.

2. The last paragraph in 4.3: 

   It is also essential to ensure that the management interfaces of
   routers are well secured as the router will usually contain a
   significant cache of neighbor addresses in its neighbor cache.

It is not clear what the authors mean by 'ensure that the management interfaces of routers are well secured'. Physical security, authenticated access, privacy protection, integrity, other? Some clarification would be useful.

I strongly agree with Lars's discuss except that I believe forbidding
overlapping fragments is essential to security.

From a review by Sam Weiler:



>I wondered who this was written for, in part because of the
>organization: it's sorted by the 'source' of the issues, not who could
>be harmed by them nor who would have to make changes to avoid them.
>It might be more useful to sort the document based on who needs to act
>to avoid particular issues.  As it is, the document provides an
>interesting read for a general audience, but I'm not sure how it will
>really be used in practice.

I strongly concur with the points Lars made about unknown destination options and headers, and think advancing this document without correcting them would be a mistake.