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

[Truman Boyes <[e-mail]>]

Greetings,

This is quite confusing from an implementation perspective; security  
is not explicitly increased by prohibiting non-encrypted tunnels but  
allowing encrypted (ESP or AH) traffic flows. Wouldn't this simply  
serve as a driver to make all tunnel encapsulations use ESP/AH?

Kind regards,
Truman Boyes


On 22/08/2009, at 3:03 PM, james woodyatt wrote:

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