[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2401bis issues (possible) resolution
> 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.
I agree with Joe that the text above (section 4.1) is too restrictive.
For instance, if security gateways are using GRE between them, there's
no use in using tunnel mode SA to protect GRE (on unneeded IP header).
> 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.
i agree with Joe on the above text. and this is not just about 2003,
but also GRE, 2893, 2473 (complicated version of 2893), 3056
(not sure if anyone is interested in applying IPsec to this),
2344, 2529 (almost obsolete).
itojun