Re: [tcpm] exegesis of 'Updates' -- was: ... reviewof draft-ietf-tcpm-tcpsecure[-10]

Joe, 

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Joe Touch
> Sent: Tuesday, September 30, 2008 3:30 PM
> To: Alfred  
> Cc: tcpm@ietf.org; iesg@iesg.org
> Subject: Re: [tcpm] exegesis of 'Updates' -- was: ... 
> reviewof draft-ietf-tcpm-tcpsecure[-10]
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Alfred   wrote:
> ...
> > Therefore my recommendation:
> > 
> > +++   Be very careful with "Obsoletes", but be generous
> > +++   with "Updates", for the benefit of RFC readers !
> 
> Well, we used to have a general rule:
> 
> 	Be conservative in what you send,
> 	be liberal in what you receive.
> 
> The second rule is bent by tcpsecure, which interprets 
> unexpected segments as attacks needing defense.

You have blown this trumphet from day one, so nothing new, really. Like it has been clarified by many folks umpteen number of times, tcp-secure improves robustness of TCP w.r.t processing in-window RSTs, SYNs and Data injection. If you think by doing so we have punched a hole in "liberality", that is your personal take. Not sure why we are even debating this now, during last call! We have moved on from this line a long time back!

> 
> As a result, we're here considering reasons not to put 
> Updates in the header, to avoid too strongly implying that 
> all TCPs everywhere need to be augmented with an 
> IPR-encumbered poor substitute for true security.

IPR issue was raised when the document was initially presented 3+ years ago!. Scott Bradner made a presentation to clarify the IPR intent and after that this, the IPR issue was never considered as a hindrance for the draft to move forward. Agreed that the IPR issue might have had some influence w.r.t the verbiage on the strength of mitigations. Lars Eggert suggested an applicability statement to be added, we added the same. Not sure why you are bringing this up now, the IPR issue was beaten to death long time back.

Again, my current understanding (which is inline with Alfred) is about "if a draft changes the TCP RFC 793 rules in some way, then it is considered as an update and we should mark it accordingly upfront for easy reference purposes" Also, update doesn't mean that "all TCP's everywhere need to be augumented with the changes". An implementer would read the mitigations, AS and the strength of recommended mitigations and would make his/her own choice!

> 
> My conclusion is that, although I agree with Alfred in 
> spirit, I can't see why we should be more liberal with 
> Updates than we are with segments we receive.

IMO, these two are completely 2 different things!

-Anantha
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjiqG4ACgkQE5f5cImnZruw4wCcDIHsrjF8mTwwMRM1N8YB7vc0
> SRYAnj6ZXFfzhFgzCzUgIMofGUu2SVgj
> =ZAPQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm