RE: [rddp] Security draft issue (4) - IPsec

[[e-mail]]

Caitlin,

> I do not see any RDDP specific vulnerabilities that are relevant
> to the use of IPsec.
> 
> A non-RDDP application enables reception of peer messages into
> application buffers. Given the nature of non-RDDP LLPs, use
> of intermediate system buffering is likely.
> 
> Once received, the Application judges the applicability of
> transport layer security to its needs. It may determine that
> the transport has provided sufficient authentication of the
> remote peer to allow acting upon the received messages without
> further validation, or it may decide to apply its own validation.
> 
> So what changes with RDDP?
> 
> Nothing, except that the intermediate system buffering is
> far less likely. That *improves* security, not worsens it.
> 
> Whether or not IPsec is in use, the Application already
> has full control of which of its buffers are exposed,
> to what extent, and for how long. Procedures to precisely
> control that exposure are already documented in the security
> draft and are not dependent on the use of IPsec or other
> transport layer security.

I think this misses the point by focusing on data instead of
control.  The thing that has changed is that RDDP exposes
a new functional interface for use over the network, providing
more opportunities for abuse by a rogue peer who misuses the
interface or an attacker who modifies the headers in transit
- the security exposure here involves the headers and the
additional functionality they enable.  In contrast to other
new functionality, the application has no possibility to
perform "its own validation" on use of the RDDP placement
interface because the application never sees the RDDP headers.

> There are also several problems with mandating IPsec
> implemenetation.
> 
> First, what is the meaning of the mandate when the RDDP
> implementation is cleanly layered over the LLP (or
> even when it is integrated with the LLP, but they
> are cleanly layered over IP)?
> 
> Surely we are not going to require that an RDDP implementation
> refuse to use a valid TCP or IP stack because it lacks
> IPsec support.

That's correct.  If the RFCs that define RDDP require that IPsec
be implemented, and an implementation that lacks IPsec nonetheless
claims to meet the requirements of the RFCs, that claim is
false.  How a customer chooses to deal with a vendor who makes
false claims is up to the customer.  I would not foresee a
requirement for RDDP to check for IPsec support.

> Secondly, we need to recognize that authentication and
> privacy can be fully achieved in many IP networks without
> any support for IPsec in the host through physical security,
> managed switches and in-network IPsec devices. In fact there
> are strong arguments why network implemented security is
> superior to host implemented security.
> 
> Further, many RDDP deployments will be in precisely these
> sort of controlled environments.

That is why an IPsec requirement would be "MUST implement"
not "MUST use" - so that IPsec would be available outside such
controlled environments without its usage being mandated in
such controlled environments.

> Lastly, requiring RDDP vendors to implement IPsec will
> in merely force mediocre implementations to be integrated
> and pre-empt the use of superior IPsec implemetnations that
> are not integrated.

I'll take not of your view that mediocre IPsec implementations
will result from an IPsec implementation requirement, but I
don't understand your "pre-empt" point, unless you were
mistakenly assuming a "MUST use" requirement for IPsec.

Thanks,
--David

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Sunday, May 09, 2004 4:08 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [rddp] Security draft issue (4) - IPsec
> 
> 
> 
> [e-mail] said:
> > 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
> 
> I do not see any RDDP specific vulnerabilities that are relevant
> to the use of IPsec.
> 
> A non-RDDP application enables reception of peer messages into
> application buffers. Given the nature of non-RDDP LLPs, use
> of intermediate system buffering is likely.
> 
> Once received, the Application judges the applicability of
> transport layer security to its needs. It may determine that
> the transport has provided sufficient authentication of the
> remote peer to allow acting upon the received messages without
> further validation, or it may decide to apply its own validation.
> 
> So what changes with RDDP?
> 
> Nothing, except that the intermediate system buffering is
> far less likely. That *improves* security, not worsens it.
> 
> Whether or not IPsec is in use, the Application already
> has full control of which of its buffers are exposed,
> to what extent, and for how long. Procedures to precisely
> control that exposure are already documented in the security
> draft and are not dependent on the use of IPsec or other
> transport layer security.
> 
> 
> There are also several problems with mandating IPsec
> implemenetation.
> 
> First, what is the meaning of the mandate when the RDDP
> implementation is cleanly layered over the LLP (or
> even when it is integrated with the LLP, but they
> are cleanly layered over IP)?
> 
> Surely we are not going to require that an RDDP implementation
> refuse to use a valid TCP or IP stack because it lacks
> IPsec support.
> 
> Secondly, we need to recognize that authentication and
> privacy can be fully achieved in many IP networks without
> any support for IPsec in the host through physical security,
> managed switches and in-network IPsec devices. In fact there
> are strong arguments why network implemented security is
> superior to host implemented security.
> 
> Further, many RDDP deployments will be in precisely these
> sort of controlled environments.
> 
> Lastly, requiring RDDP vendors to implement IPsec will
> in merely force mediocre implementations to be integrated
> and pre-empt the use of superior IPsec implemetnations that
> are not integrated.
> 
> For all of these reasons, I strongly believe that RDDP should
> remain oblivious to LLP provided security, and merely use
> whatever is there.
> 
> 
> 
> --
> Caitlin Bestler
> http://asomi.com/
> 

_______________________________________________
rddp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp