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

[Todd Glassey <[e-mail]>]

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