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

[james woodyatt <[e-mail]>]

On Aug 22, 2009, at 04:01, Yaron Sheffer wrote:
>
> In other words, the CPE is only required to verify that the *outer*  
> packet
> is protected; if it is not protected, the standard internal- 
> initiator policy
> applies, plus the gateway should drop suspicious GRE and IP-IP  
> tunnels.

Ah, I think I see where the confusion is arising.  The recommendation  
to allow IPsec AH and ESP transport mode in both directions suffice to  
police the outer packet header chain.

  R20  In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
       the forwarding of packets, to and from legitimate node addresses,
       with destination extension headers of type "Authenticated Header
       (AH)" [RFC4302] in their outer IP extension header chain.

  R21  In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
       the forwarding of packets, to and from legitimate node addresses,
       with an upper layer protocol of type "Encapsulating Security
       Payload (ESP)" [RFC4303] in their outer IP extension header  
chain.

What you would prefer to see is that section 3.2.7 be deleted in its  
entirety, which is precisely what I proposed at IETF 75 in Stockholm,  
and which failed to achieve consensus.  Perhaps, after further  
discussion, this option will seem sensible to a larger fraction of  
participants?

However, I should note that allowing outbound tunnel initiations still  
doesn't address the concern I described in my previous message.

[My proposed text for section 3.2.7 to address this concern.]
>>

>> 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.

If the perception is that flows encapsulated in tunnels must be  
subject to a stateful filtering regime to protect the interior network  
against exploits against vulnerable tunnel endpoint hosts, and if  
requiring such encapsulated flows to be encrypted with IPsec-in-IPv6- 
in-IPv6 is regarded as an acceptable way to meet the perceived need to  
protect all encapsulated flows with a cryptographic protocol, then  
simply treating outbound tunnel initiations as any other unrecognized  
protocol would be insufficient to address the objections in the  
working group to taking this draft to Last Call.

How should we proceed?


--
james woodyatt <[e-mail]>
member of technical staff, communications engineering