Re: 2401bis issues (possible) resolution

[Eric Vyncke <evyncke@cisco.com>]

At 14:01 7/10/2003 -0700, Joe Touch wrote:
>Angelos D. Keromytis wrote:
>        50 Proposed change: tunnel vs. transport mode
>>to 68). We invite one last round of comments on these items --- if you feel
>>strongly, yell!

Angelos,

I'm yelling then ;-)

Transport mode is heavily used today by security gateways in 
conjunction with another tunneling mechanism (the choice is yours 
-- the objective is to use a tunnel understood by the kernel to 
apply packet forwarding based on a FIB).

When I write 'heavily', this means by dozens of organizations for 
their site to site VPN with 100 to 5000 nodes.

All what is needed for such VPN is that both RFC 2401bis and IKEv2 
allow the negotiation/SPD/SAD for transport mode between 2 SG. 

That's all.

Regarding the security aspects of transport mode combined with 
another tunneling mechanism (like IPinIP or GRE or ...), the fact 
that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, 
dstPort=opaque) has a positive impact on the configuration of 100's 
of nodes. Security can anyway be provided by applying the SPD on the 
tunnel interface (which is just another interface where a security 
policy can obviously be enforced).

NB: the text about 'link layer' encryption has much less importance for me.

I know that this topic has been beaten to death on the mailing list. But, please 
allow transport mode between SG or better allow a SG to also act as a host (which 
is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email).

Regards

-eric


>Item 50:
>
>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway originate and/or terminate at that gateway, and as such, are hosts for the purposes of IPsec conformance (for that tunnel). Thus RFC2401 already permits the use of transport mode on this traffic.
>
>As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt
>
>We feel that it would be useful for RFC2401bis to make this distinction clear, esp. since 2401 currently suggests that transport mode support is not required at gateways, i.e. in Sec 4.1:
>
>>   Whenever either end of a security association is a security gateway,
>>   the SA MUST be tunnel mode. 
>
>It might be more specific to indicate that:
>
>For traffic originating or terminating at a gateway, that gateway MUST support the functions of an IPsec host. In particular, traffic originating or terminating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway that originates or terminates packets tunneled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow the IPsec host requirements rather than the IPsec gateway requirements.
>
>Permitting the use of transport mode in this context goes specifically to the interaction between IPsec and RFC2003 tunnels, making it a protocol issue rather than merely an implementation issue.
>
>Joe
>
>
>