Re: [tcpm] [OPSEC] draft-gont-tcp-security

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lars Eggert wrote:
Hi, Todd,

On 2009-4-14, at 22:21, Todd Glassey wrote:
Fernando Gont wrote:
Lars Eggert wrote:
I agree with Joe that some of the hardening techniques that vendors are implementing come with consequences (make TCP more brittle). To me, this
is a *reason* this document should be published via the IETF (i.e.,
TCPM) - we are probably in the best position to correctly evaluate and
classify the impact of various hardening techniques. Stack vendors have
been putting these mechanisms in to their stacks without clear
specifications and discussions of the potential upsides and downsides
that would let them make an educated decision. It seems clear to me that the vendor community is looking for guidance here, and I do believe the
IETF should give it.


This is the reason for which the output of the CPNI project was
submitted as an IETF I-D.

Yeah - so then this would be tested across all of the local TCP
implementations including the MS, AT&T *(i.e. Lachman Associates Inc)
and possibly Mentat's fast system?

Nothing would be "tested", the IETF isn't in the business of auditing TCP stacks.
Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify -

Don't the IETF standards processes "require the development of two or more independent implementations of any given protocol specification and the associated interoperability testing to document that the suite runs as advertised in the specification?" - I generally refer to that as IOT (Inter-Operability Testing). And for what its worth the IETF's mergence towards a leading edge standards process also reinforces the importance of that testing too by the way.

By comparison, in trailing edge standards processes the IOT is accomplished in the various implementations which are done in the industry. In leading edge models where there is genesis happening the testing would have to be included in the implementation of any prototypes of the stack or system and its operations.

This IMHO is the real issue with the worlds abuse of the IETF's processes - they seem to think that RFC's are standards and there are many here who use that to substantiate their technological advantage in their marketing, meaning that they derive financial value from misrepresenting this to the commercial community as well I think. The fix for that is to make RFC's unreliable for use as a protocol specification for anything other than a Standards Track effort as they should be - a Request For Comments rather than something the Trust's selling access to.

Todd Glassey
What we're talking about is describing attack vectors, potential countermeasures and the the impact (downsides) those countermeasures might come with. Implementors will need to decide for themselves if and how to apply any of these techniques to their stacks.
Which would be filed as a Use Case Document as a set lf BCP's for a protocol stanadard. This by the way is where the real value of the IETF comes in - in also telling people how to and how not to use these protocols.

Todd

Lars


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]