[secdir] Secdir Review of draft-ietf-v6ops-6204bis-09

[Matt Lepinski <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

This informational document is an update to the requirements for an IPv6 
Customer Edge Router (i.e., a router in a residence or small office that 
supports IPv6). Note that most of the security requirements (e.g., 
packet filtering / sanitation) for such a Customer Edge Router are 
provided not in this document but in RFC 6092 and RFC 2827 (which are 
included by reference, i.e., that draft states that Customer Edge 
Routers SHOULD be compliant with RFCs 6092 and 2827).

The most significant change between this draft and RFC 6204 (which it 
replaces) is that it adds a section recommending (at the SHOULD level) 
support for 6RD (RFC 5969) and DS-LITE (RFC 6333). Note that supporting 
6RD and/or DS-LITE the CPE is causes the Customer Edge Router to perform 
the additional role of encapsulation/decapsulation of tunneled packets. 
Due to the addition of support for 6RD, and DS-LITE the security 
considerations adds the additional clarification that it should be 
possible to apply filtering (as per RFC 6092) to decapsulated packets 
(i.e., apply filter rules after stripping off the outer header). Other 
than this consideration, I cannot see any additional security issues 
related to adding support for 6RD and/or DS-LITE to Customer Edge 
Routers (excepting, of course, the general 6RD/DS-LITE security 
considerations in RFCs 5969 and 6333 which need not be repeated in this 
document).

The only concern that I have is that requirement S-3 in the Security 
Considerations section is a "SHOULD" and not a "MUST". If I understand 
S-3 correctly it says "If the Customer Edge Router supports filtering as 
described in 6092, and if this feature is turned on, then it SHOULD be 
possible to apply this filtering after decapsulation (as opposed to 
applying filters before the outer tunnel header is removed)". I have 
trouble imagining why it would be a good idea to provide the packet 
filtering features described in RFC 6092 but only allow these firewall 
rules to be applied prior to decapsulation. It seems that if the user 
(who may not be well versed in IP tunneling) turns on some 
firewall/filtering service in a Customer Edge Router, that what the user 
probably wants is for the filtering rules to be applied to the packets 
"inside" the tunnel (after decapsulation) and not to packets containing 
the "outer" tunnel header. I would therefore recommend that S-3 be 
changed to a "MUST" instead of a "SHOULD".

[Note: Please correct me if I misunderstood, S-3]

As a concrete example, RFC 6092 (in REC-1) says that when a (Customer 
Premises) router receives a packet with a multicast source address, that 
this packet must not be forwarded. When the incoming packet is a 
tunneled packet, the outer IP header always has as its source address 
the IP address of the tunnel ingress device. Therefore, surely if this 
kind of filtering is turned on in a Customer Edge Router, it ought to be 
applied to the inner packet (after removal of the outer tunnel header).

- Matt Lepinski