Subject: RE: draft-touch-ipsec-vpn-06.txt

From: "Claudio Lordello" <[email-masked]>
Date: Wed, 21 Jan 2004 23:02:15 -0500

Joe Touch wrote:
> 
> The issue is exactly that the result is implementation specific, and 
> should not be.
> 

Well, if this should not be implementation specific, then perhaps it should be on standards track.

> 
> The IPsec WG recommended that we proceed with publishing it as an 
> individual informational submission (which is where we are in the 
> process), since any changes to RFC2401 would be better rolled 
> into the 
> (then pending, now emerging) update to 2401 rather than endorsed in a 
> separate WG document (such changes have already been 
> incorporated in the 
> current 2401bis draft). Our draft adds to that primarily in 
> discussing 
> the issues - which is why we are proceeding with publication as 
> informational.
> 

As far as I understood, all RFC2401bis is doing is lifting the restriction that IPsec SG's MUST only use tunnel mode, a restriction which currently exists in RFC2401. That does not mean that RFC2401bis will favor tunnel or transport modes for this application. It does not care.

Anyway, the point I would like to make is that implementations should be allowed to implement it either way, or perhaps both ways and let the user pick which way to use it via configuration. If however, it is felt by this WG that a single way should be picked, than I would ague that tunnel mode is superior because it allows the tunnel selectors to act on the tunneled traffic.

Claudio.

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Jan 2004 22:05:12 -0800

Claudio Lordello wrote:

> Well, if this should not be implementation specific, 
 > then perhaps it should be on standards track.

It is a clarification of the standard, which, as below, is already being 
incorporated in 2401bis. The specific reasons are in this draft, though.

> As far as I understood, all RFC2401bis is doing is lifting
 > the restriction that IPsec SG's MUST only use tunnel mode,
 > a restriction which currently exists in RFC2401. That does
 > not mean that RFC2401bis will favor tunnel or transport modes
 > for this application. It does not care.

Yes. But it also has a more explicit processing model which has 
implications, notably on integrating dynamic routing with SPD lookup. 
The alternate solutions involve multiple SPDs; the new architecture 
doesn't. All these have implications on whether you can use tunnel-mode 
IPsec for dynamic routing, vs. transport mode on a non-IPsec tunnel.

> Anyway, the point I would like to make is that implementations should
 > be allowed to implement it either way, or perhaps both ways and let
 > the user pick which way to use it via configuration. If however,
 > it is felt by this WG that a single way should be picked, than
 > I would ague that tunnel mode is superior because it allows the tunnel
> selectors to act on the tunneled traffic.
> 
> Claudio.

The implementation difference is as per above, not whether you want to 
use tunnel mode vs. transport with non-IPsec tunnel. That is the need 
for the clarofications to 2401 which are already underway.

As to which is better and under what circumstances, that's what the 
draft is about. Since it's not a standard - and doesn't itself modify a 
spec - it doesn't force a particular solution. What it does do is 
explain why transport + non-IPsec tunnel should be allowed, which it now 
is (or will be).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2004 11:09:46 -0800

Claudio Lordello wrote:
> Well, if this should not be implementation specific, then perhaps it
> hould be on standards track.

It is - the specific recommendations are made as standards-track in 2401bis.

> As far as I understood, all RFC2401bis is doing is lifting the
> restriction that IPsec SG's MUST only use tunnel mode, a restriction
> which currently exists in RFC2401. That does not mean that RFC2401bis
> will favor tunnel or transport modes for this application. It does not care.

See also the revised description of the processing model, notably the
use of a single SPD, as well as the many threads of this discussion on 
the IPsec and PPVPN mailing lists.

> be allowed to implement it either way, or perhaps both ways and let the
> user pick which way to use it via configuration.

One of the ways isn't consistent with the use of a single SPD.

> If however, it is felt
> by this WG that a single way should be picked, than I would ague that
> tunnel mode is superior because it allows the tunnel selectors to act on
> the tunneled traffic.
> 
> Claudio.

First, that's an artifact of a deficiency in transport mode, which we
raised a while back in the IPsec WG, notably that transport mode doesn't
have provisions for looking at IP as a transport payload (even though
it's well-defined as such - protocol type 4). That would require
revising the SPD specs in 2401 substantially, which isn't really needed,
due to the second point....

Second, it was perceived by the IPsec WG that tunnel selectors aren't
needed in the IP-over-IP case (a special case of L3VPNs). That issue was
also discussed in the IPsec WG a while ago.

Our doc (and the many previous WG discussions) addresses these issues, 
as well as others that have been raised in detail already.

Joe