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

[Ballot discuss]
Technical
=========

This is a great document overall, but there are a few small question marks
that deserve attention.

> [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] describes a method for
> creating temporary addresses on IPv6 nodes to address privacy issues
> created by the use of a constant identifier.  In a large network
> implementing such a mechanism new temporary addresses may be created
> at a fairly high rate.  This might make it hard for ingress filtering
> mechanisms to distinguish between legitimately changing temporary
> addresses and spoofed source addresses, which are "in-prefix" (i.e.,
> they use a topologically correct prefix and non-existent interface
> ID).  This can be addressed by using finer grained access control
> mechanisms on the network egress point.

I do not understand why ingress filtering mechanisms would be tracking
interface identifier assignments in this manner.  If a router's
interface has a prefix, then any address from that prefix as a source
address is correct. Please explain or remove.

> 2.1.15.  Mobile IPv6
>
>  Mobile IPv6 offers significantly enhanced security compared with
>  Mobile IPv4 especially when using optimized routing and care-of
>  addresses.  Return routability checks are used to provide relatively
>  robust assurance that the different addresses that a mobile node uses
>  as it moves through the network do indeed all refer to the same node.
>  The threats and solutions are described in [RFC3775] and a more
>  extensive discussion of the security aspects of the design can be
>  found in [RFC4225].

Is this really a security difference or simply that Mobile IPv6 has
more functionality which in turn needs security to protect those new
functions?

COMMENT-only part:
==================

See also Margaret Wasserman's comments, included at the end.

Editorial
=========

> inner and outer addresses are accpetable, and the tunnel is not being

Typo.

Review from Margaret Wasserman:
===============================

I have reviewed draft-ietf-v6ops-seccurity-overview-04.txt.

In general, I think this document is pretty good.  It is vague in some
places where more specificity might have been valuable, but that is a
relatively minor complaint.

I did find a number of small issues in the document that are included
below.  While I don't think that any of these is serious enough to
block publication of the document, the authors may want to consider
Addressing them before this document goes to the RFC editor.

Margaret


  This document also describes two matters that have been wrongly
  identified as potential security concerns for IPv6 in the past and
  explains why they are unlikely to cause problems: considerations
  about probing/mapping IPv6 addresses (Appendix A), and considerations
  with respect to privacy in IPv6 (Appendix B).

Is this document expected to update or obsolete the
earlier documents that discussed these issues?  If so, you should say
so explicitly in the abstract and the headers.

What is implied (if anything) by having these discussions in
appendices? 


2.1.9.5.  Misuse of Pad1 and PadN Options

  IPv6 allows multiple padding options of arbitrary sizes to be placed
  in both Hop-by-Hop and Destination option headers.  There is no
  legitimate reason for having a sequence of padding option fields -
  the required padding can be done with one field and there is
  currently no legitimate reason for padding beyond the next four or,
  at worst, eight octet boundary.  PadN options are required to contain
  zero octets as 'payload': there is, however, no incentive for
  receivers to check this.  It may therefore be possible to use padding
  options as a covert channel.  Firewalls and receiving hosts should
  consider dropping packets that have sequences of Pad0 or PadN options
  or use PadN of more than length 3 or 7, and should actively check
  that PadN does not have other than zero octets in its 'payload'.

s/more than length 3 or 7/more than length 7

Or explain how firewalls would know which length to use as a maximum
in different circumstances.

2.1.12.  Link-Local Addresses and Securing Neighbor Discovery

  All IPv6 nodes are required to configure a link-local address on each
  interface.  This address is used to communicate with other nodes
  directly connected to the link accessed via the interface, especially
  during the neighbor discovery and auto-configuration processes.
  Link-local addresses are fundamental to the operation of the Neighbor
  Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462].  NDP also
  provides the functionality of associating link layer and IP addresses
  provided by the Address Resolution Protocol (ARP) in IPv4 networks.

Expand "SLAAC".  Also, why does this document use NDP as an abbreviation
for Neighbor Discovery, instead of ND which is commonly used?

  In wired environments, where the physical infrastructure is
  reasonably secure, it may be sufficient to ignore communication
  requests originating from a link-local address for other than local
  network management purposes.  This requires that nodes should only
  accept packets with link-local addresses for a limited set of
  protocols including NDP, MLD and other functions of ICMPv6.

And BGP?

2.3.1.  IPv6 Networks without NATs

  The necessity of introducing Network Address Translators (NATs) into
  IPv4 networks, resulting from a shortage of IPv4 addresses, has
  removed the end-to-end transparency of most IPv4 connections: the use
  of IPv6 would restore this transparency.  However, the use of NATs,
  and the associated private addressing schemes, has become
  inappropriately linked to the provision of security in enterprise
  networks.  The restored end-to-end transparency of IPv6 networks can
  therefore be seen as a threat by poorly informed enterprise network
  managers.  Some seem to want to limit the end-to-end capabilities of
  IPv6, for example by deploying private, local addressing and
  translators, even when it is not necessary because of the abundance
  of IPv6 addresses.


I have the some of the same concerns with this paragraph as I do with
the NAP document.  NATs are not just perceived to have certain
properties, they actually have them, and even a well-informed network
administrator will need to think about how to provide similar
protections for an IPv6 network.  The NAP document explains how to do
this in a way that is less damaging to end-to-end connectivity, which
is a good thing.

  o  Development of mechanisms such as 'Trusted Computing' that will
      increase the level of trust that network managers are able to
      place on hosts.

IMO, without a reference or some specificity, this bullet is too vage
to be meaningful.


  Several of the technologies required to support an enhanced security
  model are still under development, including secure protocols to
  allow end points to control firewalls: the complete security model
  utilizing these technologies is now emerging but still requires some
  development.

While I think that the information in this section represents a good
direction for network security, I don't understand what is
IPv6-specific about it.  All of the techniques described could be used
for IPv4, and none of them are required to deploy IPv6.  I also see no
indication that work in this area is being done in an IPv6-specific
manner.  So, I'm not sure why this belongs in this document.

2.4.  IPv6 in IPv6 Tunnels

  IPv6 in IPv6 tunnels can be used to circumvent security checks, so it
  is essential to filter packets both at tunnel ingress and egress
  points (the encapsulator and decapsulator) to ensure that both the
  inner and outer addresses are accpetable, and the tunnel is not being
  used to carry inappropriate traffic.  The security discussions in
  [RFC3964], which is primarily about the 6to4 transition tunneling
  mecahnism (see Section 3.1) contains useful discussion of possible
  attacks and ways to counteract these threats.

How are IPv6-in-IPv6 tunnels different from any other IP-in-IP
tunnels?  Is this really an IPv6-specific issue?


  However, there are a small number of areas that where the available
  equipment and capabilities may still be a barrier to secure
  deployment:
  o  'Personal firewalls' intended for use on hosts are not yet widely
      available.


Do you really mean that these products are not available?  Or that
they don't contain support for IPv6?

  o  Enterprise firewalls are at an early stage of development and may
      not provide the full range of capabilities needed to implement the

4.7.  Reduced Functionality Devices

  With the deployment of IPv6 we can expect the attachment of a very
  large number of new IPv6-enabled devices with scarce resources and
  low computing capacity.  The resource limitations are generally
  because of a market requirement for cost reduction.  Although the
  IPv6 Node Requirements [I-D.ietf-ipv6-node-requirements] specifies
  some mandatory security capabilities for every conformant node, these
  do not include functions required for a node to be able to protect
  itself.  Accordingly, some such devices may not be able even to
  perform the minimum set of functions required to protect themselves
  (e.g. 'personal' firewall, automatic firmware update, enough CPU
  power to endure DoS attacks).  This means a different security scheme
  may be necessary for such reduced functionality devices.

This is also not IPv6-specific.  There are plenty of
limited-functionality IPv4 nodes on the Internet today, and few
embedded products have as few resources as many PCs that were on the
Internet in the 1990's.  I don't see why low cost embedded devices are
an IPv6-specific issue.
 
4.10.  Security Issues Due to ND Proxies

  In order to span a single subnet over multiple physical links, a new
  capability is being introduced in IPv6 to proxy Neighbor Discovery
  messages.  This node will be called an NDProxy (see [I-D.ietf-ipv6-
  ndproxy]. 

s/This node/This mechanism

Also, I think you should be clear that the IETF has only published
NDProxy as an experimental RFC, not as a standard.

  NDProxies are susceptible to the same security issues as
  the ones faced by hosts using unsecured Neighbor Discovery or ARP.
  These proxies may process unsecured messages, and update the neighbor
  cache as a result of such processing, thus allowing a malicious node
  to divert or hijack traffic.  This may undermine the advantages of
  using SEND [RFC3971].

  To resolve the security issues introduced by NDProxies, SEND needs to
  be extended to be NDProxy aware.

IMO, it does not make sense to extend SEND to be aware of a
non-standard mechanism.

  On the other hand, brute-force scanning or probing of addresses is
  computationally infeasible due to the large search space of interface
  identifiers on most IPv6 subnets (somewhat less than 64 bits wide,
  depending on how identifiers are chosen), always provided that
  identifiers are chosen at random out of the available space, as
  discussed in [I-D.chown-v6ops-port-scanning-implications].

IIDs will not be chosen at random from the available space.  I
understand why it would be helpful to prevent port scanning if they
were, but they will actually be constructed based on the MAC
address(es) of the IPv6 node.  There are a number of reasons why this
does not result in the level of protection that is implied by
considering this to be a 64-bit randomly selected field.

Appendix B.  IPv6 Privacy Considerations

  The generation of IPv6 addresses of IPv6 addresses from MAC addresses

s/of IPv6 addresses of IPv6 addresses/of IPv6 addresses

B.1.  Exposing MAC Addresses

  Using stateless address autoconfiguration results in the MAC address
  being incorporated in an EUI64 that exposes the model of network
  card.  The concern has been that a user might not want to expose the
  details of the system to outsiders, e.g., fearing a resulting
  burglary if a thief identifies expensive equipment from the vendor
  identifier embedded in MAC addresses.

A larger concern, IMO, is that by identifying the type of the
equipment, a hacker may be able to narrow down what operating system
is running and to determine which attacks are most likely to be
successful on a given system.

[Ballot discuss]
Technical
=========

This is a great document overall, but there are a few small question marks
that deserve attention.

> [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] describes a method for
> creating temporary addresses on IPv6 nodes to address privacy issues
> created by the use of a constant identifier.  In a large network
> implementing such a mechanism new temporary addresses may be created
> at a fairly high rate.  This might make it hard for ingress filtering
> mechanisms to distinguish between legitimately changing temporary
> addresses and spoofed source addresses, which are "in-prefix" (i.e.,
> they use a topologically correct prefix and non-existent interface
> ID).  This can be addressed by using finer grained access control
> mechanisms on the network egress point.

I do not understand why ingress filtering mechanisms would be tracking
interface identifier assignments in this manner.  If a router's
interface has a prefix, then any address from that prefix as a source
address is correct. Please explain or remove.

> 2.1.15.  Mobile IPv6
>
>  Mobile IPv6 offers significantly enhanced security compared with
>  Mobile IPv4 especially when using optimized routing and care-of
>  addresses.  Return routability checks are used to provide relatively
>  robust assurance that the different addresses that a mobile node uses
>  as it moves through the network do indeed all refer to the same node.
>  The threats and solutions are described in [RFC3775] and a more
>  extensive discussion of the security aspects of the design can be
>  found in [RFC4225].

Is this really a security difference or simply that Mobile IPv6 has
more functionality which in turn needs security to protect those new
functions?

See also Margaret Wasserman's comments, included at the end.

Editorial
=========

> inner and outer addresses are accpetable, and the tunnel is not being

Typo.

Review from Margaret Wasserman:
===============================

I have reviewed draft-ietf-v6ops-seccurity-overview-04.txt.

In general, I think this document is pretty good.  It is vague in some
places where more specificity might have been valuable, but that is a
relatively minor complaint.

I did find a number of small issues in the document that are included
below.  While I don't think that any of these is serious enough to
block publication of the document, the authors may want to consider
Addressing them before this document goes to the RFC editor.

Margaret


  This document also describes two matters that have been wrongly
  identified as potential security concerns for IPv6 in the past and
  explains why they are unlikely to cause problems: considerations
  about probing/mapping IPv6 addresses (Appendix A), and considerations
  with respect to privacy in IPv6 (Appendix B).

Is this document expected to update or obsolete the
earlier documents that discussed these issues?  If so, you should say
so explicitly in the abstract and the headers.

What is implied (if anything) by having these discussions in
appendices? 


2.1.9.5.  Misuse of Pad1 and PadN Options

  IPv6 allows multiple padding options of arbitrary sizes to be placed
  in both Hop-by-Hop and Destination option headers.  There is no
  legitimate reason for having a sequence of padding option fields -
  the required padding can be done with one field and there is
  currently no legitimate reason for padding beyond the next four or,
  at worst, eight octet boundary.  PadN options are required to contain
  zero octets as 'payload': there is, however, no incentive for
  receivers to check this.  It may therefore be possible to use padding
  options as a covert channel.  Firewalls and receiving hosts should
  consider dropping packets that have sequences of Pad0 or PadN options
  or use PadN of more than length 3 or 7, and should actively check
  that PadN does not have other than zero octets in its 'payload'.

s/more than length 3 or 7/more than length 7

Or explain how firewalls would know which length to use as a maximum
in different circumstances.

2.1.12.  Link-Local Addresses and Securing Neighbor Discovery

  All IPv6 nodes are required to configure a link-local address on each
  interface.  This address is used to communicate with other nodes
  directly connected to the link accessed via the interface, especially
  during the neighbor discovery and auto-configuration processes.
  Link-local addresses are fundamental to the operation of the Neighbor
  Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462].  NDP also
  provides the functionality of associating link layer and IP addresses
  provided by the Address Resolution Protocol (ARP) in IPv4 networks.

Expand "SLAAC".  Also, why does this document use NDP as an abbreviation
for Neighbor Discovery, instead of ND which is commonly used?

  In wired environments, where the physical infrastructure is
  reasonably secure, it may be sufficient to ignore communication
  requests originating from a link-local address for other than local
  network management purposes.  This requires that nodes should only
  accept packets with link-local addresses for a limited set of
  protocols including NDP, MLD and other functions of ICMPv6.

And BGP?

2.3.1.  IPv6 Networks without NATs

  The necessity of introducing Network Address Translators (NATs) into
  IPv4 networks, resulting from a shortage of IPv4 addresses, has
  removed the end-to-end transparency of most IPv4 connections: the use
  of IPv6 would restore this transparency.  However, the use of NATs,
  and the associated private addressing schemes, has become
  inappropriately linked to the provision of security in enterprise
  networks.  The restored end-to-end transparency of IPv6 networks can
  therefore be seen as a threat by poorly informed enterprise network
  managers.  Some seem to want to limit the end-to-end capabilities of
  IPv6, for example by deploying private, local addressing and
  translators, even when it is not necessary because of the abundance
  of IPv6 addresses.


I have the some of the same concerns with this paragraph as I do with
the NAP document.  NATs are not just perceived to have certain
properties, they actually have them, and even a well-informed network
administrator will need to think about how to provide similar
protections for an IPv6 network.  The NAP document explains how to do
this in a way that is less damaging to end-to-end connectivity, which
is a good thing.

  o  Development of mechanisms such as 'Trusted Computing' that will
      increase the level of trust that network managers are able to
      place on hosts.

IMO, without a reference or some specificity, this bullet is too vage
to be meaningful.


  Several of the technologies required to support an enhanced security
  model are still under development, including secure protocols to
  allow end points to control firewalls: the complete security model
  utilizing these technologies is now emerging but still requires some
  development.

While I think that the information in this section represents a good
direction for network security, I don't understand what is
IPv6-specific about it.  All of the techniques described could be used
for IPv4, and none of them are required to deploy IPv6.  I also see no
indication that work in this area is being done in an IPv6-specific
manner.  So, I'm not sure why this belongs in this document.

2.4.  IPv6 in IPv6 Tunnels

  IPv6 in IPv6 tunnels can be used to circumvent security checks, so it
  is essential to filter packets both at tunnel ingress and egress
  points (the encapsulator and decapsulator) to ensure that both the
  inner and outer addresses are accpetable, and the tunnel is not being
  used to carry inappropriate traffic.  The security discussions in
  [RFC3964], which is primarily about the 6to4 transition tunneling
  mecahnism (see Section 3.1) contains useful discussion of possible
  attacks and ways to counteract these threats.

How are IPv6-in-IPv6 tunnels different from any other IP-in-IP
tunnels?  Is this really an IPv6-specific issue?


  However, there are a small number of areas that where the available
  equipment and capabilities may still be a barrier to secure
  deployment:
  o  'Personal firewalls' intended for use on hosts are not yet widely
      available.


Do you really mean that these products are not available?  Or that
they don't contain support for IPv6?

  o  Enterprise firewalls are at an early stage of development and may
      not provide the full range of capabilities needed to implement the

4.7.  Reduced Functionality Devices

  With the deployment of IPv6 we can expect the attachment of a very
  large number of new IPv6-enabled devices with scarce resources and
  low computing capacity.  The resource limitations are generally
  because of a market requirement for cost reduction.  Although the
  IPv6 Node Requirements [I-D.ietf-ipv6-node-requirements] specifies
  some mandatory security capabilities for every conformant node, these
  do not include functions required for a node to be able to protect
  itself.  Accordingly, some such devices may not be able even to
  perform the minimum set of functions required to protect themselves
  (e.g. 'personal' firewall, automatic firmware update, enough CPU
  power to endure DoS attacks).  This means a different security scheme
  may be necessary for such reduced functionality devices.

This is also not IPv6-specific.  There are plenty of
limited-functionality IPv4 nodes on the Internet today, and few
embedded products have as few resources as many PCs that were on the
Internet in the 1990's.  I don't see why low cost embedded devices are
an IPv6-specific issue.
 
4.10.  Security Issues Due to ND Proxies

  In order to span a single subnet over multiple physical links, a new
  capability is being introduced in IPv6 to proxy Neighbor Discovery
  messages.  This node will be called an NDProxy (see [I-D.ietf-ipv6-
  ndproxy]. 

s/This node/This mechanism

Also, I think you should be clear that the IETF has only published
NDProxy as an experimental RFC, not as a standard.

  NDProxies are susceptible to the same security issues as
  the ones faced by hosts using unsecured Neighbor Discovery or ARP.
  These proxies may process unsecured messages, and update the neighbor
  cache as a result of such processing, thus allowing a malicious node
  to divert or hijack traffic.  This may undermine the advantages of
  using SEND [RFC3971].

  To resolve the security issues introduced by NDProxies, SEND needs to
  be extended to be NDProxy aware.

IMO, it does not make sense to extend SEND to be aware of a
non-standard mechanism.

  On the other hand, brute-force scanning or probing of addresses is
  computationally infeasible due to the large search space of interface
  identifiers on most IPv6 subnets (somewhat less than 64 bits wide,
  depending on how identifiers are chosen), always provided that
  identifiers are chosen at random out of the available space, as
  discussed in [I-D.chown-v6ops-port-scanning-implications].

IIDs will not be chosen at random from the available space.  I
understand why it would be helpful to prevent port scanning if they
were, but they will actually be constructed based on the MAC
address(es) of the IPv6 node.  There are a number of reasons why this
does not result in the level of protection that is implied by
considering this to be a 64-bit randomly selected field.

Appendix B.  IPv6 Privacy Considerations

  The generation of IPv6 addresses of IPv6 addresses from MAC addresses

s/of IPv6 addresses of IPv6 addresses/of IPv6 addresses

B.1.  Exposing MAC Addresses

  Using stateless address autoconfiguration results in the MAC address
  being incorporated in an EUI64 that exposes the model of network
  card.  The concern has been that a user might not want to expose the
  details of the system to outsiders, e.g., fearing a resulting
  burglary if a thief identifies expensive equipment from the vendor
  identifier embedded in MAC addresses.

A larger concern, IMO, is that by identifying the type of the
equipment, a hacker may be able to narrow down what operating system
is running and to determine which attacks are most likely to be
successful on a given system.

[Ballot comment]
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.

[Ballot discuss]
In general, this document assumes that you want a restrictive firewall
configuration--a deny by default configuration.  Many people do.  Many
people do not.  The document should make clear when advice is specific
to that configuration.  For example advice regarding unknown
destination options, unknown extension headers, etc may be reasonable
if unknown traffic is being denied, but is not reasonable if unknown
traffic is being permitted.  I believe that this advice should be
reworded to only apply to deny-by-default firewall situations and I
believe the document should be neutral on when deny-by-default or
permit-by-default is appropriate.

I believe the advice in 2.1.12 recommending that link local traffic be
restricted to network control is harmful to the internet and
inappropriate for an informational document.



From a security review by Sam Weiler:

>#1 The last paragraph of the introduction says that the appendicies
>describe "matters that have been wrongly identified as potential
>security concerns", yet Appendix B.3 (and, to a lesser degree, the
>rest of appendix B) decribes something that is an unresolved security
>concern.  I suggest moving this into the main body of the document.

>#2 Appendix B.1, discussing the difficulty of mapping an IP address to
>a physical location, says "... typically this would only be possible
>with information from the private customer database of the ISP and,
>for large sites, the administrative records of the site."  That
>neglects the public WHOIS data, noting that an ISP might be required
>by RIR policy or contract to report customer address information in
>the WHOIS.  This should be called out.

[Ballot comment]
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.

[Ballot comment]
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 .
>>>>>>
>>>>>> 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
>>>>

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I did not have time to perform an extensive review of this document, but I found that while there is a short section on security with respect to Routers here, it is rather incomplete without discussing some of the common issues with routing protocols and operations (for example, a routing table explosion attack which should be mitigated by a max-prefix limit - the settings here may be quite different between what is deployed today in IPv4 and what IPv6 would require). Is there any chance we can have this section expanded, or at least some warning text to mention that it is incomplete?

[Ballot discuss]
My overall concern with this draft is that it argues that certain
        features of existing protocols should not be used due to security
        implications, even though they are well within specification. Although
        some of these recommendations are undoubtedly useful in specific
        scenarios and this document does a good job at describing the various
        potential security implications that can arise from the use of these
        protocol features, it does _not_ discuss that the proposed limitations
        _do_ interfere with spec-conforming communication. (Because they basically
        recommend to move away from the "be liberal in what you accept" stance
        that underlies the protocol specifications themselves.)

        Consequently, the reader is left with the impression that all of the
        proposed security checks are OK to deploy with no regressions, which is
        untrue. The document does need to discuss that many of the proposed
        checks can prohibit or interfere with spec-conforming traffic for each
        of the suggestions it makes.


Section 2.1.2., para. 0:

>    destinations in a routing header that have not yet been reached by
>    the packet at the point wher it is being checked.

        Nit: s/wher/where/

>    Various forms of amplication attack on routers and firewalls using

        Nit: s/amplication/amplification/

Section 2.1.6., para. 0:

>    Specific countermeasures for particular higher layer protocols are
>    beyond the scope of this document but firewalls may be able to help
>    counter the threat by inspecting the alleged errored packet embedded
>    in the ICMPv6 error message.  The firewall and the receiving host
>    should test that the embedded packet contains addresses that would
>    have been legitimate (i.e., would have passed ingress/egress
>    filtering) for a packet sent from the receiving host.  The
>    specification of ICMPv6 and the requirement that networks should have
>    a minimum MTU of 1280 octets (as compared with ICMP and IPv4), means
>    that the ICMPv6 should normally carry all the header fields of the
>    errored packet.  Firewalls and destination hosts should therefore be
>    suspicious of ICMPv6 error messages with very truncated errored
>    packets (e.g., those that only carry the address fields of the IPv6
>    base header.)

        See the recent discussion on the TCPM list related to
        I-D.gont-tcpm-icmp-attacks on why interpretation of IP headers
        carried in ICMP payloads is problematic. For starters, the IP packet
        carried in an ICMP packet may have arrived over a different path
        and ingress/egress checking based on the path of the ICMP packet may
        not be sensible. Also, the text above second-guesses the ICMP
        specification: The latter allows senders to include as much or as
        little of a packet (within some bounds) as desired - why should a
        middlebox become suspicious if the sender emits packets that are
        fully conformant to the spec? How truncated is too
        truncated? The draft needs to be upfront about the issues this can
        introduce and that it recommends violating the spec.

Section 2.1.9.4., para. 0:

>    Even if the firewall does inspect the whole header chain, it may not
>    be sensible to discard packets with items unrecognized by the
>    firewall: the intermediate node has no knowledge of which options and
>    headers are implemented in the destination node.  Hence it is highly
>    desirable to make the discard policy configurable.  This will avoid
>    firewalls dropping packets with legitimate items that they do not
>    recognize because their hardware or software is not aware of a new
>    definition.

        We currently have the problem that excessive filtering of all IPv4
        options disables useful mechanisms that could be deployed (e.g., the
        opportunistic "I speak HIP" option discussed in the HIP WG). I'd really
        like to see a stronger statement here that discourages unreflected
        filtering of IPv6 options. The draft needs to discuss what the
        drawbacks of this choice are.

Section 2.1.9.5., para. 1:

>    IPv6 allows multiple padding options of arbitrary sizes to be placed
>    in both Hop-by-Hop and Destination option headers.  There is no
>    legitimate reason for having a sequence of padding option fields -
>    the required padding can be done with one field and there is
>    currently no legitimate reason for padding beyond the next four or,
>    at worst, eight octet boundary.  PadN options are required to contain
>    zero octets as 'payload': there is, however, no incentive for
>    receivers to check this.  It may therefore be possible to use padding
>    options as a covert channel.  Firewalls and receiving hosts should
>    consider dropping packets that have sequences of Pad0 or PadN options
>    or use PadN of more than length 3 or 7, and should actively check
>    that PadN does not have other than zero octets in its 'payload'.

        I understand the need to prevent a covert channel and hence check
        that padding payloads are zero, but I think it's problematic to prescribe
        what padding lengths and padding option sequences should be permitted,
        given that the original RFCs did not include this restriction. (Plus,
        a covert channel could be constructed using sequences of other options,
        so this doesn't plug the hole completely anyway.)

Section 2.1.10., para. 0:

>    The IPv6 router alert option specifies a hop-by-hop option that, if
>    present, signals the router to take a closer look at the packet.
>    This can be used for denial of service attacks.  By sending a large
>    number of packets containing a router alert option an attacker can
>    deplete the processor cycles on the routers available to legitimate
>    traffic.

        Has this been demonstrated to be a real issue for routers (then
        cite something), or is this describing a theoretical attack, in which
        the paragraph is overstating the dangers a bit.

Section 2.1.10., para. 5:

>    There is no reason to allow overlapping packet fragments and overlaps
>    could be prohibited in a future revision of the protocol
>    specification.  Some implementations already drop all packets with
>    overlapped fragments.

        There may be no reason in the opinion of the authors, but the specs
        currently do allow this. The whole of section 2.1.10 seems to
        significantly revise a key part of the IPv6 specification; an
        Informational document is not the place for this IMO.

[Ballot discuss]
My overall concern with this draft is that it argues that certain
        features of existing protocols should not be used due to security
        implications, even though they are well within specification. Although
        some of these recommendations are undoubtedly useful in specific
        scenarios and this document does a good job at describing the various
        potential security implications that can arise from the use of these
        protocol features, it does _not_ discuss that the proposed limitations
        _do_ interfere with spec-conforming communication. (Because they basically
        recommend to move away from the "be liberal in what you accept" stance
        that underlies the protocol specifications themselves.)

        Consequently, the reader is left with the impression that all of the
        proposed security checks are OK to deploy with no regressions, which is
        untrue. The document does need to discuss that many of the proposed
        checks can prohibit or interfere with spec-conforming traffic for each
        of the suggestions it makes.


Section 2.1.2., para. 0:

>    destinations in a routing header that have not yet been reached by
>    the packet at the point wher it is being checked.

        Nit: s/wher/where/

>    Various forms of amplication attack on routers and firewalls using

        Nit: s/amplication/amplification/

Section 2.1.6., para. 0:

>    Specific countermeasures for particular higher layer protocols are
>    beyond the scope of this document but firewalls may be able to help
>    counter the threat by inspecting the alleged errored packet embedded
>    in the ICMPv6 error message.  The firewall and the receiving host
>    should test that the embedded packet contains addresses that would
>    have been legitimate (i.e., would have passed ingress/egress
>    filtering) for a packet sent from the receiving host.  The
>    specification of ICMPv6 and the requirement that networks should have
>    a minimum MTU of 1280 octets (as compared with ICMP and IPv4), means
>    that the ICMPv6 should normally carry all the header fields of the
>    errored packet.  Firewalls and destination hosts should therefore be
>    suspicious of ICMPv6 error messages with very truncated errored
>    packets (e.g., those that only carry the address fields of the IPv6
>    base header.)

        See the recent discussion on the TCPM list related to
        I-D.gont-tcpm-icmp-attacks on why interpretation of IP headers
        carried in ICMP payloads is problematic. For starters, the IP packet
        carried in an ICMP packet may have arrived over a different path
        and ingress/egress checking based on the path of the ICMP packet may
        not be sensible. Also, the text above second-guesses the ICMP
        specification: The latter allows senders to include as much or as
        little of a packet (within some bounds) as desired - why should a
        middlebox become suspicious if the sender emits packets that are
        fully conformant to the spec? How truncated is too
        truncated? The draft needs to be upfront about the issues this can
        introduce and that it recommends violating the spec.

Section 2.1.9.4., para. 0:

>    Even if the firewall does inspect the whole header chain, it may not
>    be sensible to discard packets with items unrecognized by the
>    firewall: the intermediate node has no knowledge of which options and
>    headers are implemented in the destination node.  Hence it is highly
>    desirable to make the discard policy configurable.  This will avoid
>    firewalls dropping packets with legitimate items that they do not
>    recognize because their hardware or software is not aware of a new
>    definition.

        We currently have the problem that excessive filtering of all IPv4
        options disables useful mechanisms that could be deployed (e.g., the
        opportunistic "I speak HIP" option discussed in the HIP WG). I'd really
        like to see a stronger statement here that discourages unreflected
        filtering of IPv6 options. The draft needs to discuss what the
        drawbacks of this choice are.

Section 2.1.9.5., para. 1:

>    IPv6 allows multiple padding options of arbitrary sizes to be placed
>    in both Hop-by-Hop and Destination option headers.  There is no
>    legitimate reason for having a sequence of padding option fields -
>    the required padding can be done with one field and there is
>    currently no legitimate reason for padding beyond the next four or,
>    at worst, eight octet boundary.  PadN options are required to contain
>    zero octets as 'payload': there is, however, no incentive for
>    receivers to check this.  It may therefore be possible to use padding
>    options as a covert channel.  Firewalls and receiving hosts should
>    consider dropping packets that have sequences of Pad0 or PadN options
>    or use PadN of more than length 3 or 7, and should actively check
>    that PadN does not have other than zero octets in its 'payload'.

        I understand the need to prevent a covert channel and hence check
        that padding payloads are zero, but I think it's problematic to prescribe
        what padding lengths and padding option sequences should be permitted,
        given that the original RFCs did not include this restriction. (Plus,
        a covert channel could be constructed using sequences of other options,
        so this doesn't plug the hole completely anyway.)

Section 2.1.10., para. 0:

>    The IPv6 router alert option specifies a hop-by-hop option that, if
>    present, signals the router to take a closer look at the packet.
>    This can be used for denial of service attacks.  By sending a large
>    number of packets containing a router alert option an attacker can
>    deplete the processor cycles on the routers available to legitimate
>    traffic.

        Has this been demonstrated to be a real issue for routers (then
        cite something), or is this describing a theoretical attack, in which
        the paragraph is overstating the dangers a bit.

Section 2.1.10., para. 5:

>    There is no reason to allow overlapping packet fragments and overlaps
>    could be prohibited in a future revision of the protocol
>    specification.  Some implementations already drop all packets with
>    overlapped fragments.

        There may be no reason in the opinion of the authors, but the specs
        currently do allow this. The whole of section 2.1.10 seems to
        significantly revise a key part of the IPv6 specification; an
        Informational document is not the place for this IMO.

PROTO writeup (for the record):

---------------------
From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se]
Sent: Thursday, March 23, 2006 08:58
To: David Kessens
Cc: Bert Wijnen (Bert); Dan Romascanu (Dan); Baker Fred
Subject: draft-ietf-v6ops-security-overview-04.txt



David,

please find the request from the v6ops WG to publish the above 
document as below.




>  1.a) Have the chairs personally reviewed this version of the 
> Internet
>        Draft (ID), and in particular, do they believe this ID is 
> ready
>        to forward to the IESG for publication?  Which chair is the WG
>        Chair Shepherd for this document?
>
>

I have read this document and I believe it is ready for publication. 
I will act as chair shepherd.



>    1.b) Has the document had adequate review from both key WG members
>        and key non-WG members?  Do you have any concerns about the
>        depth or breadth of the reviews that have been performed?
>
>

The document have been analysed, referenced and discussed in several 
WGs so I believe this condition to be satisfied.



>    1.c) Do you have concerns that the document needs more review 
> from a
>        particular (broader) perspective (e.g., security, operational
>        complexity, someone familiar with AAA, internationalization,
>        XML, etc.)?
>
>

No.



>    1.d) Do you have any specific concerns/issues with this document 
> that
>        you believe the ADs and/or IESG should be aware of?  For
>        example, perhaps you are uncomfortable with certain parts 
> of the
>        document, or have concerns whether there really is a need for
>        it.  In any event, if your issues have been discussed in 
> the WG
>        and the WG has indicated it that it still wishes to advance 
> the
>        document, detail those concerns in the write-up.
>
>

I personally think that this is a highly useful document that should 
be published as is and that it will bring additional value to the 
community.



>    1.e) How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?
>
>

By my judgement there is very broad consensus for the publication of 
this document.



>    1.f) Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email to the Responsible Area Director.  (It 
> should be
>        separate email because this questionnaire will be entered into
>        the tracker).
>
>
>

No threats or appeals have been discussed around this document.



>    1.g) Have the chairs verified that the document checks out against
>        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
>        Boilerplate checks are not enough; this check needs to be
>        thorough.
>
>

This document does pass the id nits test. The nits tool says :



idnits 1.89

tmp/draft-ietf-v6ops-security-overview-04.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-
guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.

    No nits found.




>    1.h) Has the document split its references into normative and
>        informative?  Are there normative references to IDs, where the
>        IDs are not also ready for advancement or are otherwise in an
>        unclear state?  The RFC Editor will not publish an RFC with
>        normative references to IDs (will delay the publication until
>        all such IDs are also ready for RFC publicatioin).  If the
>        normative references are behind, what is the strategy for 
> their
>        completion?  On a related matter, are there normative 
> references
>        that are downward references, as described in BCP 97, RFC 3967
>        RFC 3967 [RFC3967]?  Listing these supports the Area 
> Director in
>        the Last Call downref procedure specified in RFC 3967.
>
>

It does.



>    1.i) For Standards Track and BCP documents, the IESG approval
>        announcement includes a write-up section with the following
>        sections:
>
>        *    Technical Summary
>
>        *    Working Group Summary
>
>        *    Protocol Quality
>
>    1.j) Please provide such a write-up.  Recent examples can be 
> found in
>        the "Action" announcements for approved documents.
>
>

This is an Informational document.

Kurtis & Fred

Publication requested by WG chairs (they forgot to copy iesg-secretary@ietf.org,
I reminded them to pls do so next time).


For now assigned to David, added Dan to the list of people to be informed when the status changes.