Caitlin,
> Until IPsec is mandatory-to-implement for IP hosts I see no
> justification for making it mandatory for RDDP endpoints. And
> of course if it were mandatory-to-implement for IP Hosts, RDDP
> would not have to implement it.
IPsec is mandatory-to-implement for IPv6 hosts, FWIW. The IESG
will not approve standards-track RFCs that lack mandatory-to-
implement security measures, although it's possible to reference
measures that already exist elsewhere in the environment.
If RDDP introduced no new risks above and beyond TCP or SCTP
over IPv4, then falling back to the security requirements of
those underlying protocols might be acceptable - I don't
believe this to be the case, though (i.e., there are new
RDDP-specific security risks).
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Caitlin Bestler [mailto:[email protected]]
> Sent: Saturday, May 01, 2004 5:05 PM
> To: RDDP
> Cc: [email protected]
> Subject: Re: [rddp] 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.
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.