draft-ietf-v6ops-cpe-simple-security: filtering encapsulated flows

[james woodyatt <jhw@apple.com>]

everyone--

We are not yet ready to proceed to another round of Working Group Last  
Call for this draft.  At IETF 75 in Stockholm, several participants  
objected to the language in the current revision that recommends  
allowing unsolicited inbound IPv6-in-IPv6, GREv1-in-IPv6 and IPv4-in- 
IPv6 tunnel flow initiations to proceed without applying any stateful  
filtering regime to the encapsulated flows.

Following this, I took the online discussion with some of those  
participants aside to the V6CPE Security design team email list <v6ops-residential-cpe-design-team@external.cisco.com 
> and we've been talking about various alternatives to resolve the  
issue.

This message is to report to the working group our current status.

p1.  At least one speaker at the microphone [I didn't get the name]  
offered to write sample language for appropriate recommendations, but  
I've not yet received anything.  I'm not confident I could compose an  
adequate set of recommendations myself, so I'm stalled on that line of  
effort.

p2.  I have proposed an alternative way of addressing what seems to be  
to be the underlying root concern of the remaining objections, i.e.  
that encapsulated flows might be used to exploit undisclosed  
vulnerabilities in CPE hosts and thereby obtain a route to attack  
other hosts in the residential network.  The design team seems not to  
have any major issues with it, so I'm going to propose it here to the  
working group before I go to write it into the -08 revision.

To review, here is what section 3.2.7 currently says:

> 3.2.7.  Other Virtual Private Network Protocols
>
> Residential IPv6 gateways are not expected to prohibit the use of  
> virtual private networks in residential usage scenarios.
>
> R24: In their DEFAULT operating mode, IPv6 gateways MUST NOT  
> prohibit the forwarding, to and from legitimate node addresses, with  
> upper layer protocol of type IP version 6, and SHOULD NOT prohibit  
> the forwarding of other tunneled networking protocols commonly used  
> for virtual private networking, e.g.  IP version 4, Generic Routing  
> Encapsulation, etcetera.

I propose changing this to read as follows:

> 3.2.7.  Other Encapsulation Protocols
>
> While residential IPv6 gateways are not expected to prohibit virtual  
> private networks from operating with tunnel endpoints located at  
> interior nodes, it is important to protect interior networks from  
> being reachable through routes created remotely by exploiting  
> vulnerable interior hosts.  Therefore, residential IPv6 gateways are  
> expected to require tunnel encapsulations to be protected by a  
> cryptographic protocol.
>
> R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit  
> the forwarding of packets to and from interior node addresses with  
> upper layer protocol of type IP version 6 and without Encapsulated  
> Security Payload (ESP) or Authenticated Header (AH) extension  
> headers.  A configuration option MUST be provided for lifting this  
> prohibition.
>
> R25: In their DEFAULT operating mode, IPv6 gateways MUST prohibit  
> the forwarding of packets to and from interior node addresses with  
> upper layer protocol of type IP version 4 and Generic Routing  
> Encapsulation [RFC 2784].

[I would add the missing reference to RFC 2784 and adjust the  
recommendation numbers accordingly.]

I'm now asking the working group if *this* change would be  
objectionable.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering