RE: IPsec and RDDP as a transport

There is a long history behind this one (Including the Danvers Doctrine
- when the IETF was only about 1/4 of its current size)

The idea is you MUST implement some brain dead subset of security - even
if it is completely unusable (ie. A 12 mbit software Ipsec that triple
trips your I/O Bus) and then NEVER tell your users that it exists
because it was never meant to be used.

The other alternative that most iSCSI solutions that I am seeing are
doing - Just ignore the stupid security requirements that don't apply
and ship product anyway.  If someone wants security they will build it
correctly themselves.

The scary thing is I believe in security - I am just sick of putting
required security into solutions where they don't belong.  The problem
as I see it - if a Layer 7 solution isn't allowed to point to a layer 3
security solution and say that fixes my problem, what is the use of the
Layer 3 solution, we have to specify something at layer 7 anyway.

One of these days the IETF should really fix security - and it isn't by
requiring us to all never implement DES and only implement 3DES and AES.

Bill

I am training for my first endurance event... and SAVING lives click
here to find out more!
http://www.teamintraining.org/participant/strahm-163543
 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Caitlin Bestler
Sent: Friday, May 28, 2004 10:56 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [rddp] 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.

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp