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

[Yaron Sheffer <[e-mail]>]

Hi James,

You are right. In view of R20 and R21, I would prefer sec. 3.2.7 to be
removed.

I think the extra complexity of intra-tunnel inspection of
packets-in-IPv6-in-IPv6 cannot be justified.

Thanks,
	Yaron

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of james woodyatt
> Sent: Saturday, August 22, 2009 22:04
> To: IPv6 Operations
> Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated
> flows
> 
> 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
> 
> 
> 
> 
> Scanned by Check Point Total Security Gateway.