RE: IPsec and RDDP as a transport

- I agree that "MUST implement IPSec" is a cost-adder with little 
motivation within the industry to execute.  Putting this in is likely to 
see the same response by the hardware developers as seen in other ULP which 
is to simply ignore the requirement.

- I agree that "MUST implement one-shot STag" if it does not preclude 
long-lived STag is tenable since this becomes a ULP / OS design usage issue.

- I am concerned about trying to change the RDDP / DDP headers at this 
stage of the development for security purposes.  I think the security draft 
and much of the debate to date has illustrated that documenting what the 
attacks are and allowing ULP / OS / etc. developers to determine which ones 
they will solve and which they will not at their appropriate interfaces is 
the preferred approach as it applies KISS to RDDP / DDP.  Use of KISS tends 
to avoid subsequent unanticipated vulnerabilities by constraining the 
permutations of events / conditions that lead to new attacks.

Mike



At 11:00 PM 5/31/2004, Caitlin Bestler wrote:

>[email protected] said:
> >> If one shot STags would have been an acceptable solution,
> >> why wouldn't making one shot STags a "MUST implement"
> >> be adequate?
> >
> > Because that would allow long-lived STags without requiring
> > the countermeasures for the security exposures they create.
> >
>
>An existing TCP or SCTP application is not required to
>use IPsec, even if it is present.
>
>If a "MUST Implement IPsec" requirement is added to RDDP,
>the application would still be free not to use it.
>
>Applications that choose not to use security counter-measures
>will be free to do so independently of whether you force
>IPsec circuitry onto RNICs. Therefore it cannot see how
>it can be cited as a justification for such a mandate.
>
>This sounds like very much like "IPsec should be a requirement,
>but we don't have an excuse to force that, so we'll just
>require it on every new protocol wihthout exception."
>
>If one-shot STags are availabe as a "MUST Implement"
>feature then there is *no* additional vulnerability
>created by use of RDDP. All exposed buffers are exposed
>by action of the ULP itself. If one-shot STags are always
>available, and perhaps even made the default, then there
>is no inadvertant exposure of ULP memory. That leaves
>only the same application layer security issues that
>any TCP or SCTP application running over plain IP
>would face.
>
>Whether or not you believe such applications should
>run over plain IP is irrelevant, the simple fact is
>that this is a legitimate deployment decision.
>
>Unlike the storage specialized protocols, RDDP as a
>solution will be in direct competition with non-RDDP
>applications using TCP and SCTP. Placing a requirement
>on RDDP deployments that is *not* placed on non-RDDP
>deployments can *only* be justified to the extent
>that RDDP has created a security vulnerability that
>would not be faced by the equivalent TCP/SCTP application.
>
>Even without enhancing the local interface requirements
>that is essentially already true. The local ULP has full
>control over the exposure of its local buffers. If it
>only examines those buffers *after* the permission has
>expired, or when it has other reasons to believe that
>the connection has not been compromised, then there is
>*no* additional security vulnerability.
>
>I do not believe you have disputed the above assertion,
>only that with the existing requirements for the local
>interface (and existing local interfaces) it is easy for
>an application designer to lose track of what buffers they
>have left exposed.
>
>That limited  concern can be addressed by a handful of
>requirements on the local interface. In what way has any
>more radical solution been justified?
>
>--
>Caitlin Bestler
>http://asomi.com/
>
>_______________________________________________
>rddp mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rddp