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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] 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 <jhw@apple.com> > member of technical staff, communications engineering > > > > > Scanned by Check Point Total Security Gateway.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature