Subject: RE: [tcpm] tcpsecure: how strong to recommend?

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Fri, 28 Sep 2007 21:44:01 -0700

> 
> (FWIW, I still don't get it.  If SHOULD gives the leeway not 
> to do something for whatever reason you can come up with then 
> how is it really different from MAY?  I don't know .... I 
> think there might be a distinction in your head, but I can't 
> understand it.)

Ok, I can try a brain dump :-)

Per RFC 2119

Should is defined as :

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

So, the mitigations suggested in TCP secure is RECOMMENDED to have, but
valid reasons like the ones which I pointed out may exist which can
preclude it's implementation in a particular stack. Also implications of
not adopting TCP secure is well understood since one may chose to "live"
with less robustness. Also the general feeling is that post 9/11
security has increasingly becoming important in all walks of life,
increasing robustness of a widely used protocol like TCP is not a bad
idea, so making these mitigations a SHOULD is not a big deal, IMO.

MAY is defined as :

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

Well if we view TCP secure as a optional thing, yes it makes sense to
use MAY. I think TCP secure falls in a category above "optional" and
below MUST and hence a SHOULD.

Well, this is my thinking and I am not opposed to other's thinking, but
saying that "SHOULD doesn't give leeway not to do something", is
something which I would want to dis-agree.

Hope I am clear. Again this is purely my opinion.

-Anantha

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Sep 2007 23:08:52 -0700

> idea, so making these mitigations a SHOULD is not a big deal, IMO.

First, SHOULD is a very big deal. SHOULD with IPR on a core Internet
protocol is a huge deal.

Second, security is increasingly a big deal everywhere. The bigger a
deal it is, the more likely true authentication - in the form of either
IPsec, TCP/MD5, or the latter's successors - would be the appropriate
solution to protect Internet infrastructure.

The more I hear about what this document intends and why it intends it,
the less it sounds like a standards-track anything.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Sat, 29 Sep 2007 10:34:46 -0700

> Second, security is increasingly a big deal everywhere. The 
> bigger a deal it is, the more likely true authentication - in 
> the form of either IPsec, TCP/MD5, or the latter's successors 
> - would be the appropriate solution to protect Internet 
> infrastructure.

TCP secure is about some modifications to make TCP robust in presense of
some spoofed segments. TCP/MD5/Ipsec etc., are security solutions which
are intended to protect TCP from a variety of cases.

> The more I hear about what this document intends and why it 
> intends it, the less it sounds like a standards-track anything.

We are trying to focus on the strength of mitigations of the
recommendations which is the last pending issue. I think we are
digressing here from the original intent of this thread, Mark asked me
why I believe these mitigations are SHOULD and I gave my opinion. 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Sep 2007 10:43:38 -0700

> are intended to protect TCP from a variety of cases.

TCP/MD5, and IPsec auth mode provide authentication. Authentication is
to protect TCP from spoofing.

TCPsecure protects against some spoofed TCP segments after a connection
is established.

TCP/MD5 and IPsec auth protect against all spoofed TCP segments
througout a connection's lifetime.

Fundamentally, though, all three protect against spoofing. That's what
authentication is all about.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 29 Sep 2007 23:13:23 -0700

> > 
> > TCP secure is about some modifications to make TCP robust 
> in presense 
> > of some spoofed segments. TCP/MD5/Ipsec etc., are security 
> solutions 
> > which are intended to protect TCP from a variety of cases.
> 
> TCP/MD5, and IPsec auth mode provide authentication. 
> Authentication is to protect TCP from spoofing.
> 
> TCPsecure protects against some spoofed TCP segments after a 
> connection is established.
> 
> TCP/MD5 and IPsec auth protect against all spoofed TCP 
> segments througout a connection's lifetime.
> 
> Fundamentally, though, all three protect against spoofing. 
> That's what authentication is all about.

I will have to dis-agree to this since my viewpoint is different. TCP
secure adds robustness to the processing of certain TCP segments, which
in turn helps to counter *some* spoofing attacks. Calling it as an
authentication scheme seems too far-fetched.

WHEREAS 

TCP MD5, IPsec etc., are meant to be wholesome authentication schemes.
Also this requires additional complexity in both software and hardware.

Putting TCP secure and Ipsec in the same page beats me completely.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Sep 2007 23:19:38 -0700

> authentication scheme seems too far-fetched.

You are making an assertion about whether you believe the packet is
spoofed or not based on its content matching what you expect from the
true endpoint.

That is called authentication. Weak, but still authentication.

> Also this requires additional complexity in both software and hardware.

In EITHER hardware or software. Neither one requires hardware. The level
of additional complexity is commensurate with the level of protection
they afford.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 29 Sep 2007 23:45:24 -0700

> > secure adds robustness to the processing of certain TCP segments, 
> > which in turn helps to counter *some* spoofing attacks. 
> Calling it as 
> > an authentication scheme seems too far-fetched.
> 
> You are making an assertion about whether you believe the 
> packet is spoofed or not based on its content matching what 
> you expect from the true endpoint.
> 

I am uncomfortable calling TCP secure as an authentication scheme. I
would love to hear what others have to say on this.

> In EITHER hardware or software. Neither one requires 
> hardware. The level of additional complexity is commensurate 
> with the level of protection they afford.

Agreed. Actually, I wanted to say "it may require hardware assist" 

-Anantha