Subject: Re: Remove tunnel mode from ipsec-tunnels-02?

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Sep 2006 08:14:54 +0300 (EEST)

Folks,

Unless we hear more comments on this, we propose to go forward with 
the initial suggestion of removing tunnel mode from the main 
specification.

If you have comments, please respond within a week.

For the authors,

On Wed, 12 Jul 2006, Pekka Savola wrote:
> As proposed at the v6ops meeting [0], the authors of 
> draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel mode 
> in this particular context (securing v6-in-v4 configured tunnels).
>
> This is due to issues spotted by Francis [1] and Pasi [2].  Generic "::/0 -> 
> ::/0" selectors could not be made to work without interface-specific SPDs, 
> and those cannot be signalled in IKE (that's run on top of IPv4) when the 
> tunnel would be IPv6 in a standardized way.  Generic selectors are required 
> for link-local traffic (e.g., ND) to work on the tunnel.
>
> If we go through with this proposed resolution, 
> draft-ietf-v6ops-ipsec-tunnels would only describe transport mode.
>
> Comments are welcome.
>
> [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf
> [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html
> [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html
>
> For the authors of draft-ietf-v6ops-ipsec-tunnels-02,
>
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Sep 2006 06:01:14 +0800

given that there are significant networks that operate in tunnel  
mode, including both corporate VPNs and military networks that use  
tunnel mode between encryption devices with a specific view to hiding  
interior addressing and therefore military asset distribution from  
prying eyes, this proposal seem profoundly silly.

Maybe you could remind us why the v6ops working group is supposed to  
be overriding the recommendation of the ipsec working group on how  
security is supposed to work based on what is convenient to IPv6?

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 6 Sep 2006 17:23:23 +0200

Hi Pekka, 

I think it would be a very bad idea to remove the tunnel mode from the document. To me this is clearly an extremely useful part. 

Ciao
Hannes

PS: I will try to compile a text proposal to improve the current description. 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Fred Baker
> Gesendet: Mittwoch, 6. September 2006 00:01
> An: Pekka Savola
> Cc: [email-masked]
> Betreff: Re: Remove tunnel mode from ipsec-tunnels-02?
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Sep 2006 10:57:29 +0300 (EEST)

On Wed, 6 Sep 2006, Fred Baker wrote:
> given that there are significant networks that operate in tunnel mode, 
> including both corporate VPNs and military networks that use tunnel mode 
> between encryption devices with a specific view to hiding interior addressing 
> and therefore military asset distribution from prying eyes, this proposal 
> seem profoundly silly.

Our assumption has been that transport mode is applied to a tunnel 
interface (such as IPv6-in-IPv4, GRE etc).  That hides the inner 
addresses from those observers that would have been on-path in the 
tunnel.

When IPsec tunnel mode is _NOT_ modelled as an interface, then this is 
OK though IMHO suboptimal because you cannot in practice run neighbor 
discovery, routing protocols, multicast etc. over such tunnels.  Due 
to the link-local issues mentioned previously, tunnel mode is not 
something we can recommend when it's modelled as an interface.

If there is something you disagree with in the above two paragraphs, 
maybe you should clarify what the deployment looks like, because there 
are a lot of different variations how IPsec could be applied:

  a) transport mode in host-to-host mode (end-to-end IPsec)
  b) transport mode when applied to an IP tunnel interface (e.g., 
between security gateways or a security gateway and a node)
  c) tunnel mode, not modelled as an interface
  d) tunnel mode, modelled as an interface

a) is out of scope of this document. b) seems best option by far.  c) 
can also work but has more more limited applicability as routing 
protocols, multicast, etc. don't work.  There is no interoperable 
standards solution for d) that wouldn't break IPv6 architecture hence 
it's non-starter.

> Maybe you could remind us why the v6ops working group is supposed to be 
> overriding the recommendation of the ipsec working group on how security is 
> supposed to work based on what is convenient to IPv6?

I don't see what's being overridden.  IPsec architecture allows the 
use of transport mode between a node and a security gateway.  If the 
use of tunnel mode is suboptimal, I don't see it as a problem to 
recommend another approach instead.

---

From: Fred Baker <[email-masked]>
Date: Sat, 9 Sep 2006 06:33:44 +0800

On Sep 7, 2006, at 3:57 PM, Pekka Savola wrote:
>> tunnel mode between encryption devices with a specific view to  
>> hiding interior addressing and therefore military asset  
>> distribution from prying eyes, this proposal seem profoundly silly.
>

well, yes, that's one way that tunnel mode is often implemented. It's  
hardly the only way.

> When IPsec tunnel mode is _NOT_ modelled as an interface, then this  
> is OK though IMHO suboptimal because you cannot in practice run  
> neighbor discovery, routing protocols, multicast etc. over such  
> tunnels.  Due to the link-local issues mentioned previously, tunnel  
> mode is not something we can recommend when it's modelled as an  
> interface.

I'm not entirely sure what the modeling question means to you. Are  
you objecting to the use of a tunnel header, or the configuration of  
an interface to do this?

Good grief.

So I'm sitting on a computer. I'm located, at this instant, in  
Shanghai, and in the morning will be visiting a professor from the  
Chinese Academy of Sciences. While I slept, this computer has been  
downloading email, and I am right now replying to one of yours.

The computer's connection to Cisco, where my mail services are at, is  
over the wild and woolly internet, and uses an IPSEC VPN. This  
particular VPN runs over TCP, like this:

          +-----------+-----+------+-----------------------------+
          | IP host   |IPSEC|      | +----+----------------------+
          | to        | ESP | TCP  | | IP |                      |
          | decryptor |     |      | +----+----------------------+
          +-----------+-----+------+-----------------------------+

My VPN software could just as easily run it over UDP. The point is  
that I have a security association from my host to a firewall device,  
and the datagrams I send contain an interior header that is used  
within Cisco's network and uses addressing that is not advertised to  
the world outside.

There are numerous military encryptors, some of them manufactured in  
the US for US customers and some manufactured in other places for  
NATO customers and countries that use NATO specifications, and yes,  
if you go to the right web site you can find a Cisco-manufactured  
device of this type. The description of "tunnel mode" in RFCs 4303,  
2709, and 3456 is pretty much motivated by this particular usage. In  
these devices, there is a "red" or plaintext interface and a "black"  
or ciphertext interface. Packets handed to the device on the red side  
are correlated with one of a potentially large number of security  
associations, encrypted, an IPSEC ESP or IPSEC-like header and an IP  
header added to get the thing to its decryptor, and it is fired out  
the black side. At the remote end, the payload is decrypted and  
forwarded to a red side device such as a router.

          +-----------+-----+-----------------------------+
          | IP host   |IPSEC| +----+----------------------+
          | to        | ESP | | IP |                      |
          | decryptor |     | +----+----------------------+
          +-----------+-----+-----------------------------+

And Oh yes, the router at my home office runs essentially the same  
model using civilian encryption technologies and connects me to Cisco  
when I am at home. As you say, in this case a GRE tunnel is  
configured on a virtual interface:

         +-----------+-----+-----+-----+-----------------------------+
         | IP host   |IPSEC| UDP | GRE | +----+----------------------+
         | to        | ESP |     |     | | IP |                      |
         | decryptor |     |     |     | +----+----------------------+
         +-----------+-----+-----+-----+-----------------------------+

These are each instances of a tunnel mode VPN; the "military" one is  
specifically the one recommended in RFC 4303.

Now, I will agree with you that the military version uses less bits  
and accomplishes the same thing that the two civilian versions do. If  
that's your complaint, then please state your complaint. But  
recommending against the use of tunnel mode as a class (including the  
version defined in RFC 4303) and saying that people should always use  
transport mode limits the utility of your document. The simple fact  
is that folks are going to run all of the above for a long time to  
come in both IPv4 and IPv6, sometimes because they choose to hide the  
content of the encrypted datagram, and sometimes because they by  
policy choose to run their networks in a manner in which not only the  
end systems are responsible for the security of the inter-system  
exchange, but the network administration is responsible for the  
admission of traffic to the network. Telling people that the only  
security that matters is host-to-host, and that the security of the  
network itself is irrelevant, is a good way to get laughed at.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Sep 2006 20:12:12 +0300 (EEST)

On Sat, 9 Sep 2006, Fred Baker wrote:
>>> between encryption devices with a specific view to hiding interior 
>>> addressing and therefore military asset distribution from prying eyes, 
>>> this proposal seem profoundly silly.
>> 
>> interface (such as IPv6-in-IPv4, GRE etc).  That hides the inner addresses 
>> from those observers that would have been on-path in the tunnel.
>
> well, yes, that's one way that tunnel mode is often implemented. It's hardly 
> the only way.
...

It seems you're using the term 'tunnel mode' to refer to any kind of 
IPsec protected session where there is a separate inner header that is 
protected by IPsec.  AFAICS, in IPsec specifications 'tunnel mode' has 
a more constrained meaning.  In particular, transport mode IPsec SA 
may or may not have an inner IP header, depending on what kind of 
traffic transport mode is applied to.  So, transport mode can be used 
to build tunnels with the properties you seek.

The key difference when tunneling is whether IPsec itself performs the 
tunneling operation (i.e., tunnel mode SA), or whether IPsec is 
applied to a tunnel interface, resulting in an outer and inner IP 
header (ie., transport mode SA).  In both cases the inner addresses 
are protected by IPsec.

For example, IPsec-protected GRE or L2TP tunnel is NOT typically a 
tunnel mode SA.  Conversely, you can use IPsec transport mode to 
create a tunnel with inner and outer headers.

>> When IPsec tunnel mode is _NOT_ modelled as an interface, then this is OK 
>> though IMHO suboptimal because you cannot in practice run neighbor 
>> discovery, routing protocols, multicast etc. over such tunnels.  Due to the 
>> link-local issues mentioned previously, tunnel mode is not something we can 
>> recommend when it's modelled as an interface.
>
> I'm not entirely sure what the modeling question means to you. Are you 
> objecting to the use of a tunnel header, or the configuration of an interface 
> to do this?

'modelled as an interface' here referred to representation as an 
interface, because if you have an interface, the interface should also 
have link-local addresses and securing those is difficult with tunnel 
mode.

I think we're in full agreement about the fundamental issue: there 
should be an inner IP header that's protected by IPsec.  The point is 
that it can be provided either by transport or tunnel mode, and based 
on our analysis 'tunnel mode' is a more constrained way of making such 
a tunnel and therefore less preferred.

---

From: Fred Baker <[email-masked]>
Date: Sun, 10 Sep 2006 06:15:43 +0800

On Sep 10, 2006, at 1:12 AM, Pekka Savola wrote:
> It seems you're using the term 'tunnel mode' to refer to any kind  
> of IPsec protected session where there is a separate inner header  
> that is protected by IPsec.  AFAICS, in IPsec specifications  
> 'tunnel mode' has a more constrained meaning.  In particular,  
> transport mode IPsec SA may or may not have an inner IP header,  
> depending on what kind of traffic transport mode is applied to.   
> So, transport mode can be used to build tunnels with the properties  
> you seek.
>
> The key difference when tunneling is whether IPsec itself performs  
> the tunneling operation (i.e., tunnel mode SA), or whether IPsec is  

> should be an inner IP header that's protected by IPsec.  The point  
> is that it can be provided either by transport or tunnel mode, and  
> based on our analysis 'tunnel mode' is a more constrained way of  
> making such a tunnel and therefore less preferred.

I would encourage you to not look at presentations, but at the  
controlling specifications, for the use of the term. Specifically I'm  
thinking about RFC 4303, which very explicitly defines tunnel mode as  
having an interior IP header (section 3.1.2) and transport mode as  
proceeding end to end without using an interior header (section  
3.1.1). I agree that using the term "tunnel mode" to describe other  
ways to place the interior header into the message are murkier (one  
could argue that ip-in-l2tp/gre-in-ip is running transport mode in  
each case from RFC 4303's definition, but RFC 3456 describes it as  
being in "tunnel mode" because it is within a tunnel).

As RFC 4303 uses the terms, I don't think you can support the claim  
that Transport Mode can be implemented by positioning an interior IP  
header. It may be that the thing that you are trying to excise is in  
fact that usage - transport mode being applied between tunnel  
endpoints around other kinds of tunnels.

In any event, I don't expect people to stop using L2TP to provide a  
tunnel service, or GRE as a way to overlay CE-CE VPNs.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 11 Sep 2006 13:49:11 +0300 (EEST)

I reordered the response to get the most important bits first.  As I 
suspected, we've been in full agreement about the issue all along, but 
have disagreed about what "tunnel mode" means,

On Sun, 10 Sep 2006, Fred Baker wrote:
> As RFC 4303 uses the terms, I don't think you can support the claim that 
> Transport Mode can be implemented by positioning an interior IP header. It 
> may be that the thing that you are trying to excise is in fact that usage - 
> transport mode being applied between tunnel endpoints around other kinds of 
> tunnels.
>
> In any event, I don't expect people to stop using L2TP to provide a tunnel 
> service, or GRE as a way to overlay CE-CE VPNs.

I don't expect either, which is why we're describing how to protect 
such tunnels with IPsec using transport mode.  That's actually why GRE 
and L2TP specifications either mandate supporting transport mode 
(while tunnel mode is a MAY) or specify that transport mode SHOULD be 
used.  See e.g. RFC4023 section 8.1 and RFC 3193.

And the rest, if it's still relevant,

>> I think we're in full agreement about the fundamental issue: there should 
>> be an inner IP header that's protected by IPsec.  The point is that it can 
>> be provided either by transport or tunnel mode, and based on our analysis 
>> 'tunnel mode' is a more constrained way of making such a tunnel and 
>> therefore less preferred.
>
> I would encourage you to not look at presentations, but at the controlling 
> specifications, for the use of the term. Specifically I'm thinking about RFC 
> 4303, which very explicitly defines tunnel mode as having an interior IP 
> header (section 3.1.2) and transport mode as proceeding end to end without 
> using an interior header (section 3.1.1).
> [...]

That misses the point.  Transport mode is applied "end to end" but the 
endpoints of a transport mode-protected tunnel are the tunnel 
endpoints so it is in end-to-end (with encapsulator/decapsulator being 
the endpoints).  Also, while one could correctly say "The next-header 
of an IPsec ESP header is an interior IP header if the IPsec SA is 
tunnel mode" you cannot substitute "if" with "if and only if".

---

From: [email-masked]
Date: Mon, 11 Sep 2006 11:57:03 -0400 (EDT)

Hi Fred and Pekka,

> 3.1.1).

I believe the only use of "end-to-end" in 4303 refers to transport mode
where IPv6 is the outermost header. The IPsec WG recognized that 4303 and
4301 were not totally aligned when they were published. 4301 says:

When security is
desired between two intermediate systems along a path (vs. end-to-end
use of IPsec), transport mode MAY be used between security gateways
or between a security gateway and a host. In the case where
transport mode is used between security gateways or between a
security gateway and a host, transport mode may be used to support
in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing
Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing
[ToEgWa04]) over transport mode SAs.

In my view, this paragraph almost encourages us to use transport mode in
this application.

Regards, Rich