Last Call Review of draft-ietf-v6ops-6204bis-
review-ietf-v6ops-6204bis-secdir-lc-lepinski-2012-08-01-00

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