| Newsgroups |
gmane.ietf.rddp |
| Message-ID |
<[email protected]> |
Mike,
I'm not sure I see a solution in what you're suggesting.
The situation is that if RDDP specifies long-lived
STags, then any implementation that supports them
MUST implement security to protect them. This is an
IESG requirement - fighting this results in no RFCs.
Between not wanting IPsec to be "MUST implement" and
not wanting to change the RDDP/DDP headers, how do
you propose to address this situation? Is an additional
(OPTIONAL to use) security header acceptable?
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: [email protected] [mailto:[email protected]] On
> Behalf Of Michael Krause
> Sent: Tuesday, June 01, 2004 9: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 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