New version of Security Overview published

[Elwyn Davies <elwynd@dial.pipex.com>]

A new version of IPv6 Transition/Co-existence Security Considerations 
(draft-ietf-v6ops-security-overview-05.txt) has been published today.  
This version is intended to address the comments made during IESG 
evaluation, including comments from the General Area Reviewer and the 
Security Directorate Reviewer.  A significant number of essentially 
editorial changes have been made plus some minor technical changes in 
s2.1.11 and s2.1.12.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-05.txt

The main reasons that changes have been made are:
1. To heavily emphasise that certain recommendations could lead to legal 
but unusual traffic being dropped: the document highlights (and has 
always done so) a number of areas where the IPv6 protocol specification 
leaves the door open to a malicious node sending damaging traffic that 
is technically within the specification  but would only be likely to be 
sent with malicious intent. Recommendations are made in the document 
that suggest how to minimize the risk from such traffic.  The warnings 
to administrators to be aware of the trade-offs (security gain vs 
potential for a very limited amount of legitimate traffic being dropped) 
have been reinforced, and the need for monitoring the effects of the 
rules highlighted.  The actual recommendations have not been changed 
except for one case related to link local addresses.
2. Documented the trade-off relating to the extensibility of the IPv6 
header chain: allowing unrestricted access for packets with unknown 
headers and options vs maximum security.
3. The draft previously referred to a number of expired drafts from 
which issues have been collected.  These references have been removed.  
They have been replaced by a small amount of additional explanatory text 
plus acknowledgement of the sources in the draft.
4. The effects of asymmetric routing have been considered.

Details of changes:
s1: added explanation of rationale for consideration of long term IPv4 
and IPv6 coexistence (from draft-savola-v6ops-transarch).

s2: added detailed explanation of the issue 1 above.

s2.1.1: removed ref to draft-savola-ipv6-rh-hosts and added 
corresponding explanation of the problems resulting from the rules in 
RFC1122 that permit hsost to perform local source routing.

s2.1.4: reference to draft-savola-v6ops-firewalling removed. 

s2.1.5.  the proposed tests to identify bogus errored packets embedded 
in ICMPv6 messages have been improved to take into account the 
possibility of asymmetric routing and the discussion of how much of the 
errored packet should be expected in the ICMPv6 message has been 
expanded to emphasise that an ICMPv6 message is supposed to contain *as 
much* of the packet as possible taking into account the guaranteed 
minimum MTU.

s2.1.7: the reference to draft-dupont-ipv6-rfc3041harnful has been 
replaced by draft-ietf-ipv6-privacy-addrs-v2 which contains the same 
discussion.

s2.1.8: examples of situations in which reverse DNS records are checked 
has been given to give better justification of the need for reverse DNS 
updating.

s2.1.9: reference to draft-savola-v6ops-firewalling removed and note of 
incomplete specification in RFC2460 added.

s2.1.9.1: changed statement that destination options are not processed 
en route (correct but incomplete) to statement that only hop-by-hop 
options are processed at every node on the path.  Added recommendation 
stating that vendors and administrators may currently choose to ignore 
the RFC2460 rules on header processing in middleboxes to give enhanced 
security without serious consequence, but that they should be aware that 
future extensions might change the situation.

s2.1.9.2, para 3: added explanation that it is the requirement for 
detailed knowledge of the layout of header types that would be 
problematic if headers did not use TLV format.

s2.9.2, para 5: applies to hop-by-hop options as well as destination 
options.

s2.1.9.3: with reference to item 3 above, documented the dilemma for 
administrators of facilitating extensibility by allowing 'unknown' 
headers and options unfettered access vs securing the network by 
limiting access to well-known headers and options.  Emphasized 
recommendation for using configurable firewalls that can be updated to 
take account of newly standardized headers but will still remove unknown 
items.

s2.1.9.4: removed reference to draft-krishnan-ipv-hopbyhop and provided 
a brief summary of the problems documented therein.

s2.1.9.5: redrafted the recommendation on what are 'reasonable' 
sequences of padding options (unreasonable to pad beyond next 8 octet 
boundary, each pad should be done with one PadN of the right size or a 
sequence of Pad1 options of the right length)

s2.1.10: highlighted that packets with overlapping fragments are a major 
security risk. Redrafted last four paragraphs to clarify the 
recommendations.

s2.1.11: added a concrete analysis to demonstrate that non-final 
fragments smaller than  50% of the guaranteed minimum MTU are 
unreasonable and should be considered for dropping.

s2.1.12: Removed discussion of IPv4 link local addresses.  Removed 
port-based MAC address security as a suggested mitigation for securing a 
link layer.  Expanded the discussion of the advisability of filtering 
link local addresses used for other than control and management 
functions, including discussion of zone identifiers and the consequences 
of potentially overlapping link local address spaces at nodes with 
multiple interfaces.

s2.1.15.1: rmoved reference to draft-savola-ipv6-rh-ha-security.

s2.2: reference to draft-cmetz-v6ops-v4mapped-api-harmful and 
draft-itojun-v6ops-v4mapped-harmful removed and explanation of the 
issues in these drafts incorporated.

s2.3.2: reference to Trusted Compting architecture added.

s4.1: removed reference to draft-ietf-v6ops-v6onbydefault and added a 
note about the risks of tunneling transition mechanisms and VPNs.

s4.3: added examples of management interfaces that need to be secured.

s4.4: modified comments on link local addresses in line with s2.1.12.  
Added example of using multiple subnets on a single link.

s4.9: added clarification of 'finer grained access control mechanism' 
and reference to draft-ietf-ipv6-privacy-addrs-v2.

s4.10: redrafted last para as a reminder that SEND will need to be 
extended if NDproxies are standardized rather than as a requirement in 
the here and now.

s7: Acknowledgments extended to cover the authors of the various expired 
drafts no longer referenced.

s8: References updated: expired drafts removed and draft->RFC changes 
incorporated.  RFC3041 replaced by draft-ietf-ipv6-privacy-addrs-v2 
throughout.

Other minor editorial changes were also made.

Regards,
Elwyn
for the authors