RE: IPsec and RDDP as a transport

 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Michael Krause
> Sent: Tuesday, June 01, 2004 6:14 AM
> To: [email protected]
> Subject: RE: [rddp] 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; at least for 10GbE the "MUST implement IPSec" requirement would be
not just a cost-adder - it will be simply impossible to productize an RNIC
with IPSec for the next 3-4 years, so the requirement is going to be
ignored.

Leonid


> 
> - 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
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>