Last Call Review of draft-ietf-v6ops-6204bis-

Request Review of draft-ietf-v6ops-6204bis
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-08-14
Requested 2012-06-28
Authors Hemant Singh, Wes Beebee, Chris Donley, Barbara Stark
Draft last updated 2012-08-01
Completed reviews Genart Last Call review of -?? by Meral Shirazipour
Genart Telechat review of -09 by Meral Shirazipour (diff)
Secdir Last Call review of -?? by Matt Lepinski
Assignment Reviewer Matt Lepinski
State Completed
Review review-ietf-v6ops-6204bis-secdir-lc-lepinski-2012-08-01
Review completed: 2012-08-01


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 


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