[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2401bis issues (possible) resolution





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 writes:
> 
>>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, plea
>>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, 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 pur
>>poses 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 requir
>>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 suppor
>>
>>t the functions of an IPsec host. In particular, traffic originating or termin
>>ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003
>>) MAY use transport mode. A gateway that originates or terminates packets tunn
>>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 the
>>
>>interaction between IPsec and RFC2003 tunnels, making it a protocol issue rat
>>her than merely an implementation issue.
>>
>>>Joe
>>>
>>>
>>>