[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2401bis issues (possible) resolution
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
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.
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).
>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.