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

[Joel Jaeggli <joelja at bogus.com>]

IETF list omitted for brevity...

I think this is exactly the kind of discussion that this document
needed, and I glad that we've finally managed to stimulate it.

In my own opinion:

I do belive that implementation advice is in scope for the ietf.

We should plow operational experience with our protocol stack and it's
limitations back into the standards process,

We should avoid producing advice on general cases that would result in
protocols becoming more rather than less brittle except when absolutely
necessary.

We should be mindful that existing deployed implementations are unlikely
to change based solely on recommendations.

joel

Lars Eggert wrote:
> Hi,
> 
> <all hats off>
> 
> On 2009-4-14, at 1:38, Joe Touch wrote:
>>>> Advice in making a hardened version of TCP would be useful to the
>>>> implementation community.
>>>
>>> To a large extent this is what draft-gont-tcp-security is about.
>>
>> Implementation advice is outside the scope of the IETF. It's not even
>> operational, IMO.
> 
> I do believe there is value in having a document that would inform a
> stack vendor of various potential attack vectors against a TCP stack and
> what techniques exist to harden their stacks.
> 
> 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.
> 
> Yes, there is a fine line here, where some of the hardening techniques
> introduce some new assumptions on what the segment flow of a valid
> connection looks like, etc. It will be important to accurately describe
> the downsides of some of these techniques, especially where they could
> result in valid connections being dropped.
> 
> Lars
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf