Re: 2401bis issues (possible) resolution

["Angelos D. Keromytis" <angelos@cs.columbia.edu>]

Right --- the mods Joe suggested seem acceptable.
-Angelos

In message <3F857EC1.8070907@isi.edu>, Joe Touch writes:
>
>
>Angelos D. Keromytis wrote:
>> Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode.
>
>Except, as pointed out in my earlier post of 10/7/03:
>
>RFC2401, Sec 4.1:
>
> > Whenever either end of a security association is a security gateway,
> > the SA MUST be tunnel mode.
>
>I.e., this explicitly precludes the use of transport modes between 
>gateways, except if considering that non-IPsec tunnels render those 
>gateways into hosts, so host rules should apply. Although that latter 
>interpretation technically complies with 2401, sec 4.1 could be 
>misconstrued to imply that gateways should not support transport mode. 
>That is where 2401bis could be clarified, as per (e.g.) the mods I 
>suggested in that earlier post.
>
>> Issue #50 is a lot more aggressive, as we read it.
>
>Agreed.
>
>> In message <5.1.0.14.2.20031009161624.02e13520@localhost>, Eric Vyncke write
>s:
>> 
>>>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, pl
>ea
>>>se 
>>>allow transport mode between SG or better allow a SG to also act as a host (
>wh
>>>ich 
>>>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, no
>t 
>>>
>>>traffic on a 'link' in general. Packets using 2003-style tunnels at a gatewa
>y 
>>>originate and/or terminate at that gateway, and as such, are hosts for the p
>ur
>>>poses of IPsec conformance (for that tunnel). Thus RFC2401 already permits t
>he
>>>use of transport mode on this traffic.
>>>
>>>>As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.tx
>t
>>>>
>>>>We feel that it would be useful for RFC2401bis to make this distinction cle
>ar
>>>
>>>, esp. since 2401 currently suggests that transport mode support is not requ
>ir
>>>ed 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 suppo
>r
>>>
>>>t the functions of an IPsec host. In particular, traffic originating or term
>in
>>>ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC20
>03
>>>) MAY use transport mode. A gateway that originates or terminates packets tu
>nn
>>>eled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow
> t
>>>he IPsec host requirements rather than the IPsec gateway requirements.
>>>
>>>>Permitting the use of transport mode in this context goes specifically to t
>he
>>>
>>>interaction between IPsec and RFC2003 tunnels, making it a protocol issue ra
>t
>>>her than merely an implementation issue.
>>>
>>>>Joe
>>>>
>>>>
>>>>