Re: IPsec and RDDP as a transport

[email protected] said:
> I think the discussion with Caitlin has reached the point
> where a summary and opening up the discussion to others is
> in order.
>
> In essence, Caitlin strongly suggests that RDDP's security
> requirements should be derived by considering it as a transport
> protocol optimization and looking to what is required of other
> transport protocols.  SCTP (RFC 2960) is an obvious place to
> look.
>

I would phrase it slightly differently.

a) An RDDP application has full control of the exposure of its
memory, and already has the tools to ensure that it is as
safe as a non-RDDP application using the LPP directly
independently of what form of anti-spoofing is in use.

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.

I am particularly concerned with RDDP implementations
that ride cleanly on top of the LLP or even just the IP layer.
An IPsec requirement actually penalizes clean layering.

Beyond that, I oppose restrictions on development of low
cost solutions for environments that have no need of
host level authentication -- either because there is already
adequate anti-spoofing control in the local network or
because the application requires true end-to-end
authentication anyway and would not trust host
level authentication.

Yes I know they don't have to use it, but "Must Implment"
means they have to pay for it.

> I think that this is viable (although I'm probably in for a
> lengthy discussion with the security ADs - part of my job
> as a WG chair), but there are three important consequences
> that I'd like to see comments on:
>
> (1) The "no IPsec" (or equivalent mechanism) level of requirement
> 	would apply only to implementations that restrict all STags
> 	to be one-shot (single use in some sense).
>

This is the heart of the "additional need" requirement, which should
be the only question here (although I suspect some of the pressure
is a backdoor effort to retroactively eliminate all hosts that do
not have IPsec support -- something that if done should be done
at the IP layer).

Basically, my argument is that the tools are available to control
the exposure of STags independently of the use of IPsec. If the
application chooses not to use them, so be it. The application
was free to choose not to use IPsec even if we require it to
be implemented.

I believe David's essential concern is that applications will not
realize the security implications of using long-lived STag.

There is some merit to that argument, but I believe that stating
that the local interface SHOULD encourage STags to have the
shortest lifespan that the application requires would be adequate.
And as noted earlier, I favor minimalism in requiremets.

I also agree with John Hufferd's comments that we do not want
to encourage development of local interfaces that limit the
flexibility of STags. Changing the default to one-shot I have
no problem with, but not forcing it.

> (2) Implementations that allow longer-lived STags would in all
> 	likelihood be subject to a stronger security requirement
> 	due to the increased application exposure created by
> 	long-lived STags.
>
> (3) STag values will probably have a randomness requirement to
> 	make them hard to guess.  See the discussion of the SCTP
> 	Initiate Tag and its randomness requirements in RFC 2960
> 	(e.g., Section 5.3.1).
>

It's hard to make a MUST out of a randomness requirement.
A SHOULD would certainly be appropriate, however.

But these are piling up mandates for the local interface. We
should think about whether we really want to do that, and if
so whether there should be a distinct draft for that purpose.

--
Caitlin Bestler
http://asomi.com/