Adaptec and Transport Mode

[Black_David@emc.com]

> Dear IPS Chair,

Since this was apparently addressed to me, I guess I need to respond.
Let me start with the area of agreement.

-- Scope of IPS security specifications

>   A. Prime Directive: IPS Security MUST be implemented. It should be
> 		"end-to-end".
> 
>       Why? Jeffery Schillers
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

FWIW, it is my understanding is that this draft did not make it through
IETF Last Call.  I'm expecting significant revisions to it that will
hopefully lend more clarity to discussions such as this one.

>   Implications : 1) Anything less than end-to-end is outside 
> 				the scope of IPS security, hence should not
be
> 				specified by this WG. In fact, it is
orthogonal.
>                       Ideally, one ought to implement "additional"
> 				nested tunnel for VPN, firewall etc. over
and
> 				above end-to-end.
>                   2) It is fair game to implement less than end-to-end
> 				(firewall, gateway etc.) in lieu of
end-to-end,
>				if their customers are happy with it. There
is 
>                       no need to claim compliance with "IPS security"
>				in that case. The WG should not encourage
this
>				usage, if it still believes in the above
"prime
>				directive".

I agree with these implications, although I would have used "in
addition to" instead of "in lieu of" in the second one and omitted
its last sentence, as there's nothing wrong with firewalls, gateways,
etc.  As Bernard Aboba has already posted, this was discussed in
Minneapolis, and the next revision of the IPS Security draft will
contain text to make this set of issues clearer.

Moving on to the areas of disagreement ...

-- RFC 2401 transport mode requirements

Shridhar started from RFC 2401 and somehow came up with a "SHOULD
use transport" recommendation when two hosts are communicating.
That is incorrect - not only does RFC 2401 not contain any such
recommendation , but it contains the following (Section 4.1, p.9):

	Two hosts MAY establish a tunnel mode SA between themselves.

As those terms defined by RFC 2119, this "MAY" is inconsistent with
"SHOULD use transport" between two hosts.  Please read the RFCs
*before* undertaking to lecture the WG on their contents.

-- Technical arguments for tunnel mode

>   From my understanding, all the technical arguments "for" TUNNEL
> 	have been addressed and all shot down,

I believe that to be incorrect.  I have never seen a refutation of
the technical argument that there are advantages to being able to reuse
existing IPsec implementations that do not do transport mode well (e.g.,
IPsec security gateway implementations).  

>   Without getting into implementation details, as an implementer of
> multi-Gig silicon, I can assure you that implementing security gateway
> is a very expensive problem compared to end-point security which can be
> implemented as part of a highly integrated silicon.

That is a misleading exercise in strawman demolition.  Tunnel mode can
be implemented as part of end-point security, as RFC 2401 requires hosts
to support tunnel mode.  There is no text in any of the IPS drafts that
REQUIRES a security gateway implementation.

-- Analysis and Disposition of Request

In the absence of WG rough consensus, Shridhar is asking that the
WG chairs and/or others force the IPS WG to adopt some form of
a "MUST implement" requirement for transport mode.  RFC 2119
defines MUST as follows:

  1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
     the definition is an absolute requirement of the specification.

and goes on to say:

  6. Guidance in the use of these Imperatives

     Imperatives of the type defined in this memo must be used with care
     and sparingly.  In particular, they MUST only be used where it is
     actually required for interoperation or to limit behavior which has
     potential for causing harm (e.g., limiting retransmisssions)  For
     example, they must not be used to try to impose a particular method
     on implementors where the method is not required for
     interoperability.

So, we are looking for an "absolute requirement" "for interoperation or
to limit behavior which has potential to cause ham (e.g., limiting
retransmissions)."

One of Shridhar's Adaptec colleagues tried to make the argument that
transport mode is required for interoperation (i.e., that omitting it
will cause interoperability problems) and was "shot down" in Minneapolis
on the basis that IKE handles this negotiation (see SA Attribute 4 in
Section 4.5 of RFC 2407).  That leaves "limit behavior which has
potential for causing harm".  If it were extraordinarily difficult or
impossible to use tunnel mode for end-to-end security, or to configure
it for such use, the resulting inability to use and/or barriers to the
use of end-to-end security could fall into that category, but Shridhar
says:

>   I am not saying that tunnel can not be used for end-to-end.

In other words (taking out the double negative), tunnel mode can
be used for end to end security.  Discussion on the list has confirmed
that not only does RFC 2401 permit this, but it actually works in
practice ("running code", what a concept ...).

Since Shridhar's request is contrary to RFC 2119, it is hereby DENIED,
especially as it appears to "try to impose a particular method on
implementors where the method is not required for interoperability"
which is forbidden by RFC 2119.

Shridhar also mentions the performance difference between tunnel and
transport mode - the current rough consensus on the list is that this
difference merits discussion and a lower-case "should" for transport
mode when an implementor considers performance to be an important
consideration.

-- Ulterior Motives

Since Shridhar has chosen to speculate on the motives of others ...

>   Regarding consensus ..., is it possible that most of the "tunnel"
>	enthusiasts 
>   a) do not want to see security as part of IPS anyway, and/or
>   b) want security, but not end-to-end.

... I find it necessary to report to the WG that in a heated hallway
discussion prior to the Tuesday meeting of the IP Storage WG in
Minneapolis, some of Shridhar's Adaptec colleagues made it clear to
me in no uncertain terms that the change to "MAY implement transport
mode" would cause a major product cost increase for Adaptec.  I will
leave it to others to draw their own conclusions ...

-- Conclusion

The request to impose a "MUST implement transport mode" requirement
in the absence of WG rough consensus is hereby DENIED.  This issue
needs to stay closed if people want these drafts to make it
through WG last call before Yokohama.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------