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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf