Re: Security draft issue (4) - IPsec

On May 1, 2004, at 9:31 PM, [email protected] wrote:

> On to the last, and most difficult open issue from Seoul - what
> should RDDP (specifically the security draft) have to say about
> a mandatory-to-implement security mechanism.  Here's an extract
> from the minutes:
>
>   Section 9 - Should we require IPsec, and therefore implement
>   this section, or make it optional? Suggestion that it be made
>   "mandatory-to-implement, optional-to-use." It was observed that
>   IPS had a similar section because it needed it. Also, now that
>   there is the IKEv2 specification to refer to, the problem is no 
> longer
>   so difficult to document.  Look at IKEv2 and new "Cryptographic
>   Algorithms for IKEv2" draft.  If these are used this section in
>   the RDDP security draft may not be necessary, as an IKEv2
>   reference will be adequate.
>
>   (4) Core question: Should we say that IPsec is mandatory for RDDP?
>   Secondary question: What parts do we actually require? (IKEv2?)
>
> I have heard a couple of comments on this that deserve some further
> elaboration.
>
> - Q: RDDP is part of the transport, can't we defer the security
> 	requirements to whatever the ULP above the transport requires?
> - A: Yes, but that would only cover the payloads, as the ULP won't
> 	know anything about RDDP headers.  To follow this approach,
> 	either we have to have a way to protect the RDDP headers or to
> 	make their protection unnecessary (e.g., as SSL/TLS makes
> 	protection of TCP headers unnecessary).  The latter approach
> 	will have to deal with RDDP enabling direct placement of network
> 	data into ULP/application memory, which seems to be a resource
> 	that deserves protection.
> - Q: Isn't IKEv2 a lot to ask of implementers?
> - A: Possibly - the discussion in Seoul was around the fact that IKEv2
> 	should clean up a lot of IKEv1's interoperability problems,
> 	possibly obviating the need to profile IKEv1.  OTOH, IKEv2 is
> 	a relatively new protocol.
>
> This is for discussion.  I observe that the IESG will insist on a
> solid answer to "What is the mandatory-to-implement security for 
> RDDP?".
>
>

Actually, I have the opposite question/objection.

RDDP rides on top of standard reliable IP Transports (SCTP and TCP).

So why should a problem solved at those layers also be solved by RDDP?

The one sense that RDDP is "transport layer" is that it is below the 
application
layer. As such, it should not be making any presumption that RDDP 
applications
need more security or authentication than the transport layer itself 
would provide.

Until IPsec is mandatory-to-implement for IP hosts I see no 
justification for
making it mandatory tor RDDP endpoints. And of course if it were 
mandatory-to-
implement for IP Hosts, RDDP would not have to implement it.