RE: IPSEC target and transport mode

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Mon, 1 Apr 2002 Black_David@emc.com wrote:

> I need to clarify one thing in John's post --
>
> Transport mode was never an unqualified "MUST implement".  Rather
> it was qualified in Huntington Beach as "MUST implement when RFC
> 2401 says it MUST be implemented".  That difference is crucial,
> as the following paraphrased Q&A from the Huntington Beach
> meeting on this topic illustrates:
>
> Q: Is this a subterfuge to force FCIP to implement Transport mode?
> A (David Black): No, gateway implementations would still be allowed,
> 	and Transport mode would not be required.
>
> As I said earlier, in my opinion, WG rough consensus for an unqualified
> "MUST implement" for transport mode cannot be obtained (e.g., see above
> Q&A).  My current opinion is that the performance argument (one less
> encapsulated header on the wire for each packet) for transport mode is
> sufficient to justify only a SHOULD, not a MUST.  OTOH, Bernard's
> "complicates routing considerably" argument could justify a MUST,
> although I'm not sure whether the VPN/remote access considerations that
> motivate it apply to IP Storage.

I don't understand why we should soften the language. If a device looks
like a host, why shouldn't it need to act like one?

> Meanwhile, several problems with RFC 2407 have turned up in the area of
> transport/tunnel mode negotiation -
>
> (1) Section 4.5 says that for transport/tunnel encapsulation mode:
>            If unspecified, the default value shall be assumed to be
>            unspecified (host-dependent).
> 	That needs to be overridden to say that the default mode in
> 	the absence of negotiation MUST be tunnel mode.  I have no idea
> 	how text with such an obvious interoperability issue got approved.

I think the idea is that you aren't supposed to not be explicit in what
you want; you're supposed to list a mode always.

Take care,

Bill