[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi James,

I support your intention, which is to allow tunneled traffic only if it is
cryptographically protected. But I don't understand the new text. It just
doesn't clarify that we're talking of tunneled traffic. How about:

R24: In their DEFAULT operating mode, IPv6 gateways MUST prohibit the
forwarding of tunneled networking protocols, e.g.  IPv4-in-IPv6, Generic
Routing Encapsulation etc., unless such protocols are protected by applying
ESP or AH extension headers to the encapsulating IPv6 packet. A
configuration option MUST be provided for lifting this prohibition.

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.

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 1:25
> To: IPv6 Operations
> Subject: Re: draft-ietf-v6ops-cpe-simple-security: filtering encapsulated
> flows
> 
> On Aug 21, 2009, at 14:26, james woodyatt wrote:
> > [I wrote:]
> >>
> >> 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.
> 
> Ugh.  This needs wordsmithing.
> 
> How about this instead:
> 
> > 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 unless the encapsulated packets
> > have Encapsulated Security Payload (ESP) or Authenticated Header (AH)
> > extension headers.  A configuration option MUST be provided for
> > lifting this prohibition.
> 
> I think that more clearly defines the regime I'm proposing.
> 
> 
> --
> 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