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

From: james woodyatt <[email-masked]>
Date: Fri, 21 Aug 2009 14:26:35 -0700

everyone--

We are not yet ready to proceed to another round of Working Group Last  
Call for this draft.  At IETF 75 in Stockholm, several participants  
objected to the language in the current revision that recommends  
allowing unsolicited inbound IPv6-in-IPv6, GREv1-in-IPv6 and IPv4-in- 
IPv6 tunnel flow initiations to proceed without applying any stateful  
filtering regime to the encapsulated flows.

Following this, I took the online discussion with some of those  
participants aside to the V6CPE Security design team email list <[email-masked] 
 > and we've been talking about various alternatives to resolve the  
issue.

This message is to report to the working group our current status.

p1.  At least one speaker at the microphone [I didn't get the name]  
offered to write sample language for appropriate recommendations, but  
I've not yet received anything.  I'm not confident I could compose an  
adequate set of recommendations myself, so I'm stalled on that line of  
effort.

p2.  I have proposed an alternative way of addressing what seems to be  
to be the underlying root concern of the remaining objections, i.e.  
that encapsulated flows might be used to exploit undisclosed  
vulnerabilities in CPE hosts and thereby obtain a route to attack  
other hosts in the residential network.  The design team seems not to  
have any major issues with it, so I'm going to propose it here to the  
working group before I go to write it into the -08 revision.

To review, here is what section 3.2.7 currently says:

> 3.2.7.  Other Virtual Private Network Protocols
>
> Residential IPv6 gateways are not expected to prohibit the use of  
> virtual private networks in residential usage scenarios.
>
> R24: In their DEFAULT operating mode, IPv6 gateways MUST NOT  
> prohibit the forwarding, to and from legitimate node addresses, with  
> upper layer protocol of type IP version 6, and SHOULD NOT prohibit  
> the forwarding of other tunneled networking protocols commonly used  
> for virtual private networking, e.g.  IP version 4, Generic Routing  
> Encapsulation, etcetera.

I propose changing this to read as follows:

> 3.2.7.  Other Encapsulation Protocols
>
> 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.
>
> 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.
>
> R25: 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 4 and Generic Routing  
> Encapsulation [RFC 2784].

[I would add the missing reference to RFC 2784 and adjust the  
recommendation numbers accordingly.]

I'm now asking the working group if *this* change would be  
objectionable.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Aug 2009 15:25:19 -0700

On Aug 21, 2009, at 14:26, james woodyatt wrote:
> [I wrote:]

Ugh.  This needs wordsmithing.

How about this instead:

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 22 Aug 2009 14:01:14 +0300

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: [email-masked] [mailto:[email-masked]] 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
> 
> >> 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.
> 
> > 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.
> 
> Scanned by Check Point Total Security Gateway.

---

From: james woodyatt <[email-masked]>
Date: Sat, 22 Aug 2009 12:03:36 -0700

> applies, plus the gateway should drop suspicious GRE and IP-IP  

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?

---

From: Truman Boyes <[email-masked]>
Date: Sun, 23 Aug 2009 00:58:42 -0400

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:

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

---

From: james woodyatt <[email-masked]>
Date: Sat, 22 Aug 2009 22:33:37 -0700

> serve as a driver to make all tunnel encapsulations use ESP/AH?

Yes.  I'm not sure I can explain how this is supposed to increase  
security, but if consensus in the working group emerges around these  
recommendations and the draft can proceed through working group last  
call, then that's good enough for me.

---

From: Mark Smith <[email-masked]>
Date: Sun, 23 Aug 2009 18:45:16 +0930

On Sat, 22 Aug 2009 22:33:37 -0700

> call, then that's good enough for me.

Maybe I haven't fully understood the question, however isn't the answer
as simple as the benefits of IPsec over cleartext? Even the
better-than-nothing-mode of IPsec, while vulnerable to
man-in-the-middle attacks during session setup, has a much smaller
window of opportunity for exploitation over clear text traffic.

Regards,
Mark.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 23 Aug 2009 13:49:28 +0300

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

> Sent: Saturday, August 22, 2009 22:04
> To: IPv6 Operations

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2009 08:56:21 +1200

> window of opportunity for exploitation over clear text traffic.

Not to mention the fact that other secure VPN techniques such as
IP-over-TLS will still be fine through a conforming CPE.

    Brian

---

From: Mark Baugher <[email-masked]>
Date: Mon, 24 Aug 2009 11:33:31 -0700

The node that accepts the IKE phase 1 presumably has some acl or  
credential requirement to control access - or could have.  I thought  
that this was the idea behind the original recommendation.

Mark

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Aug 2009 11:59:21 -0700

> that this was the idea behind the original recommendation.

I'm always getting confused about whether we're presuming that the  
interior node is well secured or that the interior node has some  
hypothetical vulnerability that can be remotely exploited to obtain  
access to the rest of the interior network.  I'm often making the  
wrong assumption in the wrong context, and I suspect I just don't have  
sufficient network security expertise to know which assumption to make  
in what scenario.

Hence, my tendency to defer to the people with more credible claims to  
such expertise.  Let them take the heat for mistakes of that  
category.  That's what they get paid to do.

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Aug 2009 07:06:22 +0930

Hi James,

On Mon, 24 Aug 2009 11:59:21 -0700

> sufficient network security expertise to know which assumption to make  

I'm assuming a well secured interior node. When exploits are
discovered in good VoIP handset vendors' devices, and they fix them,
rather than saying "these devices shouldn't be plugged into the
Internet", then I think any device / OS, from a good vendor, which has
the more common possibility of being plugged into the Internet than a
VoIP handset, can also be assumed to be well secured by default (if
the end user switches it off, that's their problem). I think vendors are
going to have to accept that once they give a device the possibility of
being connected to the Internet, there'll be somebody who will (and
possibly lots of people, if a different but related use emerges). The
only safe choice for a vendor is secured by default.