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

Re: 2401bis issues (possible) resolution




Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode.
Issue #50 is a lot more aggressive, as we read it.
-Angelos

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
>>
>>
>>