2009/2/14 Lars Eggert [email protected]
> during the discussions around the TCP implementation deficiencies
> publicized by the Outpost24 last fall, we discussed with CERT-FI and others
> in that community that the IETF would offer to be the venue for publishing
> such a document.
>
It has always been in our mind to bring the results of our project
("Security Assessment of the Transmission Control Protocol (TCP)" to the
IETF.
We have already done this for another document ("Security Assessment of the
Internet Protocol") that was part of the same project. In July 2008, the UK
CPNI released that document, and the next week after the release we publish
an IETF I-D version of the same document.
We have done the same thing with this new TCP document. I have already
submitted an IETF I-D version of the document, in the hope that the IETF
will work on this stuff. The document is entitled "Security Assessment of
the Transmission Control Protocol (TCP)", and the filename is
draft-gont-tcp-security-00.txt.
> The goal would be to document techniques that stack vendors are employing
> to harden their stacks.
>
This is sort of what we have done. However, not only have we documented
techniques that stack vendors have implemented to harden their stack, but
have also performed an assessment of the IETF specs themselves, and have
also proposed mitigation techniques for known issues (on which there had
never been advise on how to deal with them). We had a preliminar version of
our paper sometime in 2006, but then it went through a throrough review
process. That's why it ended up being published this
month.
> They asked us to wait until vendors had a chance to deploy patches to the
> latest round of vulnerabilities, and we haven't heard back from them since
> late last year. (Which reminds me to shoot them an email.)
>
I have been in the loop (for some time, at least), and have also been in
very close contact with a number of vendors. For instance, an excerpt of our
large TCP document (that discussed the specific issues that had been
publicized by Outpost24) was made available to vendors in the hope of
providing vendors with advice on how to deal with those issues.
I don't really know how the "patching" work is going on... but at least a
few months ago, I would say that many (most?) vendors were not really
working in patches. And to some extent it might make sense, as some of the
issues have more to do with having the applications controlling the amount
of resources that they are using, than with TCP trying to limit the amount
of resources per app at the TCP level.
> I believe such a document would be fully in scope for TCPM,
>
I believe both tcpm and opsec could be possible candidates for this
document.
> but obviously the involvement of the stack vendors is critical to ensure
> this is a document that has practical relevance.
>
To the extent that was possible, vendors *have* been involved in the review
process of our TCP security document. However, at times it gets hard to get
vendors involved in the IETF process. For the most part, they feel they are
not heard, and that participating in the IETF has a low ROI (Return Of
Investment).
We have had some experience in this arena with the document "ICMP attacks
against TCP" that we are still pursuing within tcpm. I was able to get
involved from the following "vendors":
* NetBSD
* OpenBSD
* FreeBSD
* Linux
* Cisco
* Sun
* HP
* ExtremeNetworks (IIRC)
* ... and others
but we nitpicked on the document for ages. Virtually everybody in the vendor
community couldn't believe that we were having such discussions about that
stuff. So at some point most people argued that "they had already voiced
their opinion, but they felt that it didn't made a difference". After all,
they had already implemented the stuff discussed in the document (and so had
others), so they really didn't have much of a reason to get involved in the
process.
I'd be glad to discuss a plan to pursue this work within the IETF.
Thanks!
Kind regards,
--
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
