Re: IPsec and RDDP as a transport

On May 29, 2004, at 1:02 AM, [email protected] wrote:

> It appears that the option of allowing RDDP implementations
> to only support one-shot STags is not acceptable, so I believe
> the rough consensus of the RDDP WG is that all implementations
> MUST support long-lived STags.  Send any objections to the list.
>
> Unfortunately, the following security alternative that Caitlin
> proposes is not acceptable to the IESG:
>
>> b) There are alternate forms of anti-spoofing that address
>> the Security issues for applications not using the available
>> tools just as well as IPsec does. Foremost of these would
>> be use of IPsec within routers combined with managed
>> switches.
>
> In essence, if the RDDP protocols can reasonably be used in
> situations that create security exposures (e.g., on the public
> Internet), then the IESG requires that countermeasures to those
> exposures be "MUST implement".  At the London IETF in 2001, an
> attempt was made in the IESG plenary to remove a similar "MUST
> implement" requirement for IPsec for one of the IP Storage protocols
> on roughly the above basis (if you want IPsec, use an external
> IPsec gateway, but don't make it a protocol requirement).  The
> IESG shot this attempt down in flames.  Unless one is a glutton
> for punishment, I don't recommend repeating this experiment.
>

If one shot STags would have been an acceptable solution,
why wouldn't making one shot STags a "MUST implement"
be adequate?

Under the more draconian IPsec "MUST implement" solution
the application would be free to not use that capability. So
why not allow the application the very same option to not
use one-shot STags?

One-shot STags as the default, enforced by the local interface,
would be at least a minor change to existing local interfaces --
but it would be minor compared to adding IPsec to an existing
implementation.

I also repeat my objection to requiring that a cleanly layered
RDDP implementation solve problems on a lower layer.
This is *extremely* bad policy. The SCTP mapping in particular
is quite suitable for implementation *over* SCTP.

The probable effect of forcing inclusion of IPsec in an RNIC
design will be RNICs that support *only* MPA/TCP over IPv4.
It will *discourage* development of such SCTP and/or IPv6
solutions, and it will discourage Motherboard based solutios
that run above the IP layer.

Or it will simply result in implementations that can support
IPsec in name only: over 10,000 endpoints supported, but
only 300 if IPsec is enabled.

Is there any dispute on the technical merits here. I believe
everyone understands that for the overwhelming majority
of RDDP streams that host-implemented IPsec is a bad
idea. Other anti-spoofing solutions work just as well (including
in-network IPsec) and can be applied only when needed.
The market-place is a far better forum to work out these
tradeoffs. Attempting to force the market to buy something
that it would not is a bad idea, especially when the risk
is carried entirely by the voluntary endpoints using RDDP
and in no way by the network as a whole.