Re: [secdir] draft-ietf-tcpm-tcpsecure

[Nicolas Williams <[e-mail]>]

On Fri, Aug 14, 2009 at 05:33:13PM -0700, Anantha Ramaiah (ananth) wrote:
> There was a big thread that went in TCPM some time back on this.
> Initially the mitigations were tagged as "if you implement TCP secure
> then all these are a MUST", such a statement gave a leeway for
> implementers to chose whether or not they want to implement tcp-secure.
> But some folks felt that since TCP secure has an IPR on it should
> probably not have MUST in them at all, another argument was since TCP

If the issue is IPR then the WG/IETF could choose to make this RFC not a
Standards-Track RFC, but an FYI, and optionally drop the normative
RFC2119 language (or make those MUSTs; doesn't matter much to me, if the
RFC is to be Informational).

It'd be silly to make this a Standards-Track RFC with not a single
REQUIRED to implement feature in it -- all implementations of anything,
anywhere, could then claim to be compliant.  If there was at least one
REQUIRED to implement then you could choose to make other encumbered
features RECOMMENDED, or OPTIONAL.  But no RTI feature at all makes no
sense to me.

> secure is mostly useful only for long lived connections (like BGP), then
> it may not be applicable to hosts and only applicable to routers. I

So what?  Implementors who don't care for this feature wouldn't be bound
to implement it just because this RFC says it's a MUST.  Implementors
who don't implement it would just not be compliant with this RFC, but
nothing says they have to be.

> didn't (so as many others) didn't buy this argument, but since it was
> not going anywhere Lars stepped up with the suggestion of applicability
> statement to be added to this draft (I haven't seen any other TCP
> related RFC which has an AS in it, FWIW) and the rest is history. I
> seriously doubt whether the chairs/Lars/WG would like to fallback to
> MUST/MUST/SHOULD.

I'd like to hear from them.

> As far as the SYN corner case workaround we chose not to talk about the
> fix for the same in the draft since the corner case exists in RFC 793
> and nothing to do with the current SYN mitigation.

OK.  Maybe this should be stated in the I-D.

Nico
--