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

From: Mark Allman <[email-masked]>
Date: Mon, 24 Sep 2007 13:44:44 -0400

Folks-

The seeming last issue with the tcpsecure document is how strong to
recommend the various mitigations.  To review, there are three
mitigations for RST, SYN and data injection attacks.  The question is
whether to say that a TCP (1) MAY use all these mitigations, (2) SHOULD
use all these mitigations or (3) SHOULD use the mitigations for the RST
& SYN attacks and MAY use the data injection mitigation.  Clearly there
are other permutations (and one could also bring MUST and MUST NOT into
the conversation), however these three options have been voiced.  If you
have some other permutation then voice it.

In the meeting in Chicago we took a "visual hum" and the tally looks
like this:

      all SHOULDs: 4
      all MAYs: 3
      two SHOULDs and a MAY: 8

So, our inclination is to go with option (3) from my list above.  If you
think this is the wrong way to go please yell---especially if you are
not reflected in the 15 folks who took part in the visual hum.

Thanks,
allman

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 24 Sep 2007 15:34:21 -0700

I'd encourage others to weigh in on this. I'm uncomfortable with our
making recommendations to change TCP's fundamental behavior as a SHOULD
on the basis of a handful of representatives.

Joe

Mark Allman wrote:
> ------------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Sep 2007 23:29:10 -0300

>not reflected in the 15 folks who took part in the visual hum.

My inclination is for option (2) (all MAYs).

FWIW, I did not attend the last IETF.

Thanks,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Allman <[email-masked]>
Date: Mon, 24 Sep 2007 22:47:08 -0400

> on the basis of a handful of representatives.

Joe, I hear you.  Ted and I chatted today and are also a bit leery
here.  We'd very much love to hear from others with opinions.

allman

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Sep 2007 09:07:05 +0300 (EEST)

> FWIW, I did not attend the last IETF.

Likewise.

As a note, I do not see this as a comment on the technology or the 
modifications.  What I don't like is the concept that new TCP 
standards track documents would define what all TCP implementations 
implement.  Instead they should just define how to implement a 
particular modification if a vendor chooses to do so.  If we need to 
mandate what vendors must implement in order to claim compliance with 
'TCP', we need to update RFC 1122 or write a normative version of the 
TCP roadmap document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Agarwal, Anil" <[email-masked]>
Date: Tue, 25 Sep 2007 08:02:14 -0400

Mark, Joe et al,
 
My inclination is to suggest -
   "all SHOULDs"
 
A second choice would be -
    "two SHOULDs and a MAY"
 
As far as I can see, the proposed mechanisms bring value to users and to the Internet at large, 
are relatively simple and backward compatible and do not (seem to) break anything. 
I would be hesitant leaving them as "MAY"; vendors should be strongly encouraged 
to implement security mechanisms.
 
Regards,
Anil
 
Anil Agarwal
ViaSat Inc.
Germantown, MD

________________________________

From: Joe Touch [mailto:[email-masked]]
Sent: Mon 9/24/2007 6:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] tcpsecure: how strong to recommend?

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 25 Sep 2007 08:25:57 -0400

> FWIW, I did not attend the last IETF.

I was at the meeting, and I think my hand is included in the "all MAYs"
above.  My personal opinion was that regardless of licensing terms, I
think having known IPR on something that we recommend all TCP hosts to
do is distasteful.  Since the tcpsecure solution isn't generally useful,
but only needed for specific cases, and the antispoof document described
alternatives, I don't feel that the benefits of SHOULD outweigh the
downside, so I'll say "all MAYs" again.

---

From: David Borman <[email-masked]>
Date: Tue, 25 Sep 2007 07:54:56 -0500

I voted (3) at the meeting.  My vote is with the understanding that  
the whole tcpsecure document is *not* becoming part of the base TCP  
specification, but is an optional addition that implementors may  
choose whether or not to implement.  If they do choose to implement  
it, then within that context my vote is for two SHOULDs and a MAY.

If my understanding is incorrect, and we are voting on SHOULD/MAY for  
making these part of the base TCP specification, then I would change  
my vote to (2) all MAYs.
			-David Borman

On Sep 25, 2007, at 1:07 AM, Pekka Savola wrote:

> particular modification if a vendor chooses to do so.  If we need  
> to mandate what vendors must implement in order to claim compliance  
> with 'TCP', we need to update RFC 1122 or write a normative version  
> of the TCP roadmap document.
>
> --

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Sep 2007 16:54:11 +0300

Hi,

> on the basis of a handful of representatives.

this brings up an important point we need to clarify. The tcpsecure  
document contains a technical specification for multiple TCP  
mechanisms to protect against certain attacks.

However, RFC 2026 recommends that technical specifications should  
also come with a statement of applicability, i.e., something that  
says when the technical specification should or should not be used.  
Many documents don't have this, and often that isn't an issue. The  
tcpsecure document is missing this piece, too, but in this case I  
believe this is causing some confusion.

For some folks, this lack of a clear applicability statement means  
that the tcpsecure mechanisms become part of the "must-implement" set  
of TCP. To other folks, the MUST/SHOULD/MAY in the current document  
*are* a kind of applicability statement.

I think it would be helpful if we would tease apart applicability  
statement and technical specification. What were missing is consensus  
on the applicability of the proposed set of mechanisms. During the  
discussion around this document, I've heard basically two choices  
being expressed:

(1) all TCP stacks should implement tcpsecure

(2) only TCP stacks that expect to support a significant number of  
connections for which the described attacks are possible should  
implement tcpsecure

This is important to scope the discussion we're currently having on  
SHOULD vs. MAY.

If the applicability is (1), a SHOULD with its should-have-a-really- 
good-reason-to-ignore semantics is a pretty strong statement that  
affects all stacks.

Whereas if the applicability is (2) or something else that is more  
restricted than (1), a SHOULD is essentially without effect for  
stacks that don't consider themselves to fall under the conditions  
stated.

Lars

PS: Here is the relevant section from RFC2026:

3.1  Technical Specification (TS)

    A Technical Specification is any description of a protocol, service,
    procedure, convention, or format.  It may completely describe all of
    the relevant aspects of its subject, or it may leave one or more
    parameters or options unspecified.  A TS may be completely self-
    contained, or it may incorporate material from other specifications
    by reference to other documents (which might or might not be  
Internet
    Standards).

    A TS shall include a statement of its scope and the general intent
    for its use (domain of applicability).  Thus, a TS that is  
inherently
    specific to a particular context shall contain a statement to that
    effect.  However, a TS does not specify requirements for its use
    within the Internet;  these requirements, which depend on the
    particular context in which the TS is incorporated by different
    system configurations, are defined by an Applicability Statement.

---

From: "Agarwal, Anil" <[email-masked]>
Date: Tue, 25 Sep 2007 10:04:15 -0400

All,

On Tue 9/25/2007, Wesley Eddy wrote:

> above.  My personal opinion was that regardless of licensing 
> terms, I think having known IPR on something that we 
> recommend all TCP hosts to do is distasteful.  Since the 
> tcpsecure solution isn't generally useful, but only needed 
> for specific cases, and the antispoof document described 
> alternatives, I don't feel that the benefits of SHOULD 
> outweigh the downside, so I'll say "all MAYs" again.

I am surprised to hear that these TCP enhancements carry IPR 
and licensing terms.

Are there other standard or standards-track TCP enhancements 
that require licensing?

Anil

Anil Agarwal
ViaSat Inc.
20511 Seneca Meadows Parkway, Suite 200
Germantown, MD 20876
[email-masked]
ViaSat Brings your Network to Life

---

From: Ted Faber <[email-masked]>
Date: Tue, 25 Sep 2007 09:52:05 -0700

> I am surprised to hear that these TCP enhancements carry IPR 

https://datatracker.ietf.org/ipr/421/

> Are there other standard or standards-track TCP enhancements 

Not so many.  You can look for yourself at: 
https://datatracker.ietf.org/ipr/about/

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Tue, 25 Sep 2007 10:30:31 -0700

Some comments inline... 

> -----Original Message-----
> From: David Borman [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 5:55 AM
> To: Pekka Savola
> Cc: [email-masked]; Fernando Gont; [email-masked]
> I voted (3) at the meeting.  My vote is with the 
> understanding that the whole tcpsecure document is *not* 
> becoming part of the base TCP specification, but is an 

How does a document become part of the base specification (793 for
eg;-)? Does a document which clarfies some things left/out or corrects
errors like (1122 for eg;-) become part of the base specs?

> optional addition that implementors may choose whether or not 
> to implement.  If they do choose to implement it, then within 
> that context my vote is for two SHOULDs and a MAY.

My understanding is the strength of a proposal is determined by the
language used (SHOULD/MUST/MAY etc.,) and that covers everything
including guiding an implementor to implement the proposal or not. For
eg:- a TCP stack need not implement TCP secure mitigations at all but
MUST implement slow start for example. 

If someone determines (I assume they know what they are doing in most
instances ;-) that proposals recommended in a particular RFC is needed
either in part/full then they would put resources to get that
accomplished in their stack. Isn't the "standard" way ?

Or are you saying "base specfication" is something akin to what the
roadmap document is talking about under the section "basic
functionality"?

Confused,
-Anantha

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 25 Sep 2007 16:47:32 +0200

all SHOULDs (I was not at the meeting)

I have been persuaded in the past, during IETF Last Calls, that  MAY might as
well be MAY NOT in which case it conveys very little.  If it is worth expressing
in an RFC, then it is worth a SHOULD.

Tom Petch

---

From: "Mitesh Dalal \(mdalal\)" <[email-masked]>
Date: Tue, 25 Sep 2007 11:34:50 -0700

A point to note is that we neither obsolete nor update rfc793, so if we
make a requirement as SHOULD or MUST does not cause an implementation to
go out of spec (just as in RFC3168 makes SHOULD/MUST recommendations,
but does not mean that
all rfc793 implementations are out of spec)

The whole discussion becomes relevant only if we are really updating
rfc793, so as long as you see these changes as standalone, the question
of SHOULD/MUST/MAY  become self explanatory in the right context. 

So, in that sense I propose the changes as MUST. If an implementation
claims
compliance with these changes, than this (MUST) is the way it has to be
implemented.

my 0.02
Mitesh

> From: Mark Allman [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 7:47 PM
> To: Joe Touch
> Cc: [email-masked]
> > making recommendations to change TCP's fundamental behavior as a 
> > SHOULD on the basis of a handful of representatives.
> 
> Joe, I hear you.  Ted and I chatted today and are also a bit 
> leery here.  We'd very much love to hear from others with opinions.
> 
> allman
> 
> 
> 
>

---

From: Mark Allman <[email-masked]>
Date: Tue, 25 Sep 2007 14:47:38 -0400

Hat off ... 

This is a lot of hang wringing mumbo-jumbo, I think.  It seems to me ...

  + If a standards track document says "a TCP SHOULD do X" then as a
    particular TCP evolves it really ought to do X unless the
    implementers have a very good reason not to do X.

  + If a standards track document says "a TCP MAY do X" then as a
    particular TCP evolves the implementers have discretion to do X or
    not to do X based on their understanding of the issues.

  + If a standards track document says "a TCP SHOULD do X subject to
    conditions Y or scope Z" then as a particular TCP implementation
    evolves it really ought to do X if it falls within the given
    conditions or scope.

Why is this harder than that?

Hat on ...

It seems that currently the first two bullets apply to tcpsecure.  That
is, the document does not have any scoping or conditions.  Lars (and
others) has suggested that perhaps we need to add some scoping to the
document through an applicability statement.  That is certainly an
option.  If folks think that we should be adding such an applicability
statement before worrying about SHOULD vs. MAY then please say so.  (It
seems to me that thus far that has been a minority position.  I am happy
to change my view of this based WG input, naturally.)

allman

---

From: Tim Shepard <[email-masked]>
Date: Tue, 25 Sep 2007 14:59:40 -0400

> compliance with these changes, than this (MUST) is the way it has to be

I think we've lost something important with MAY/SHOULD/MUST stuff.

Recall Lars Eggert's pointing out the need for an applicability
statement (in general and in particular).

It seems the mitigations described in this draft should be implemented
in any TCP which is going to be used for things which use TCP in such
a way that they will be vulnerable (where the IP addresses of both
ends and the port number of one end are knowable by an attacker) *or*
something else could be done to reduce vulnerability to such an
attack.

But its not completely clear to me that here we are trying to define a
protocol, the sort of thing which needs things like MAY/SHOULD/MUST to
ensure that interoperability goals will be met.

A somewhat serious security problem was discovered some time ago.
This draft documents one vendor's approach to solving this problem.
There are other ways of solving this problem.  It's not clear that a
standard is needed here to ensure interoperability of systems.

What is our goal here with this document?

Can the English word "should" be used in an RFC (without making it uppercase)?

I'd be happy publishing this document as informational and not
sweating the MAY/SHOULD/MUST stuff.  Just make them lowercase and make
the text make sense.

How's BTNS coming along?   Will we be seeing BGP over BTNS anytime soon?
(I've not been following BTNS too closely recently).

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Sep 2007 12:34:18 -0700

> Why is this harder than that?

The other nuance is:

	if you do A you MUST do B

i.e., dependencies of the choices within the protocol. That's useful to
capture, even using MUST/MAY/SHOULDs, but it should be clear enough from
the textual context.

> to change my view of this based WG input, naturally.)

I think that MAY is fine without conditions.

I think that SHOULD should always have conditions - even if to
explicitly state "all TCPs SHOULD" in the most general case.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Sep 2007 12:35:31 -0700

> in an RFC, then it is worth a SHOULD.

There are plenty of RFCs that describe MAYs, FWIW. MAY means that it's
permissible and compliant to do something.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Tue, 25 Sep 2007 14:14:08 -0700

>     implementers have a very good reason not to do X.

Since, all these discussions about started due to TCP secure, let me use
the same as an example. There is nothing wrong in making all mitigations
SHOULD since the "very good reason" can be one of :-

- I don't care about security/robustness of TCP connections and hence my
products don't need to implement these.
- well I do care about security but I always use additional protection
like MD5 or IPsec and hence implementing this is optional. I'll think
about it.
- I like the mitigations in the draft and I see them lightweight and
I'll go ahead and implement them, but since these are tagged SHOULD I
may have a knob to control this behaviour.
- I definetely would want to implement these. Even though it is a
SHOULD, to me it is like a MUST.

So what I am tryng to say is: it is upto the implementers to interpret
and implement it if they wish to do so. Saying SHOULD is not an issue
since it gives enough leeway for all of the above scenarios.

But I am open to the idea of adding a generic applicability statement
like : "these mitigations are useful in blah blah... Conditions etc., "
Already if I remember correctly we do have some text to that effect in
the draft, but we can polish it further or formalize it.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Sep 2007 14:47:51 -0700

> SHOULD since the "very good reason" can be one of :-

... I'll number these for references:

#1
> products don't need to implement these.
#2
> like MD5 or IPsec and hence implementing this is optional. I'll think
#3
> may have a knob to control this behaviour.
#4
> since it gives enough leeway for all of the above scenarios.

I don't think SHOULD covers #1 very well above, and it arguably doesn't
voer case 2 either. SHOULD really intends to mean "MUST unless you know
you know a specific reason that would be undesirable".

That's why I think some of us (myself included) prefer MAY for all (with
the caveat that there can be MAY for the whole set, and the additional
relative requirements, i.e., If you do A, you MUST do B.)

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Sep 2007 15:12:07 -0700

> (I've not been following BTNS too closely recently).

See the Goals and Milestones at:
http://www.ietf.org/html.charters/btns-charter.html

Joe

---

From: Tim Shepard <[email-masked]>
Date: Wed, 26 Sep 2007 07:42:53 -0400

> http://www.ietf.org/html.charters/btns-charter.html

Cool.  But that is only a (partial) answer to my first question.  From
the status of Goals and Milestones on that IETF WG charter page, I
cannot tell if the result of the BTNS WG is something that is
sufficiently far along that "go do BTNS" is a viable alternative to
this "tcpsecure" draft.  Presumably I could read all the drafts that
are there and form my own opnion, but the queue of things that I ought
to read soon is much deeper than what I will be able to read soon.

(For those attempting to follow along... I believe the need that
 triggered this tcpsecure draft was also (one of?) the trigger(s) that
 led to the BTNS WG effort.    This tcpsecure draft is a collection of
 hacks (which appear to solve the problems as we understand them now)
 while the BTNS effort was started in an attempt to solve the problem
 in an architecturally correct and more robust way.)

At some point there's a decision to be made, recommend what's in the
tcpsecure draft, or recommend what BTNS has produced.

So I ask: is BTNS succeeding such that it is a viable alternative to
this tcpsecure draft?

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 07:01:46 -0700

>  in an architecturally correct and more robust way.)

FWIW:

tcpsecure reduces the impact of attacks on TCP that presume knowledge of
the socket pair (src/dst IP, src/dst port), the impetus of which was
attacks on BGP

as noted in RFC4953 (antispoof) discusses protections for such services,
and more direct protections using authentication mechanisms such as
TCP/MD5 (which we have a group revising - stay tuned...) and IPsec.

IPsec is sometimes not used in routers because of the need to configure
preshared keys or certificate authority information; BTNS enables IPsec
without either

BTNS has a large number of potential uses beyond BGP, though. TCP/MD5
and its alternates - despite the formers similar need for preshared keys
- may be more likely to be more widely used for the BGP case.

I.e., as was noted in antispoof, there are many ways to address this
problem, and the problem is of impact only for certain connections.

> tcpsecure draft, or recommend what BTNS has produced.

Or the successor to TCP/MD5, or existing IPsec - and that recommendation
will probably involve collaboration with the Security Area.

> So I ask: is BTNS succeeding such that it is a viable alternative to

One of many alternatives, yes. The only alternative, no.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 26 Sep 2007 07:41:52 -0700

Few points :-

- It is true that TCP secure recommendations might be useful for long
lived sessions like BGP. But there are many applications using TCP which
also could benefit from the proposed changes. The TCP secure changes
needs to be viewed as a standalone thing, since it focusses in providing
robustness to TCP connections w.r.t some spoofing attacks. 

- TCP secure changes are not going to solve the "world hunger problem".
Ipsec and TCP secure are completely orthogonal since Ipsec is generic
security solution with it's own pros and cons whereas TCP secure
attempts to illustrate some known issues w.r.t some TCP spoofing attacks
and proposes mitigations to the same.

- The WG is also talking about replacing the TCP MD5 with a more generic
TCP security algorithms. This came out of the need to provide security
at layer 4. I know some people would dis-agree but that is a different
story.

- TCP secure, TCP MD5, TCP advanced security algorithms, IPsec are all
different tools with varying degrees of complexity and usage. A user can
chose to use one of them depending on his/her requirements. Telling
people to only use IPsec is akin to saying "always fly in business
class". Yes I have used this analogy before, but this is one whih popped
up in mind after today's coffee :-)

So, I would not draw some comparisions between TCP secure and other
"security" solutions including BTNS etc., These need to be viewed upon
independently.

Well, I am speaking out of experience resulting from dealing with
working on many products which use TCP and confronting the differing
requirements imposed by those, so needless to say, OMMV.

-Anantha

> Cool.  But that is only a (partial) answer to my first 
> question.  From the status of Goals and Milestones on that 
> IETF WG charter page, I cannot tell if the result of the BTNS 
> WG is something that is sufficiently far along that "go do 
> BTNS" is a viable alternative to this "tcpsecure" draft.  
> Presumably I could read all the drafts that are there and 
> form my own opnion, but the queue of things that I ought to 
> read soon is much deeper than what I will be able to read soon.
> 
> (For those attempting to follow along... I believe the need 
> that  triggered this tcpsecure draft was also (one of?) the 
> trigger(s) that
>  hacks (which appear to solve the problems as we understand 
> them now)  while the BTNS effort was started in an attempt to 
> solve the problem  in an architecturally correct and more robust way.)
> 
> At some point there's a decision to be made, recommend what's 
> in the tcpsecure draft, or recommend what BTNS has produced.
> 
> So I ask: is BTNS succeeding such that it is a viable 
> alternative to this tcpsecure draft?
> 
> 			-Tim Shepard
> 			 [email-masked]
>

---

From: <[email-masked]>
Date: Wed, 26 Sep 2007 17:46:49 +0100

Two things that seem clear from this quite long email thread:

1) many of the people expressing opinions on this are the same ones that
expressed opinions at the meeting in Chicago

2) there is definite lack of agreement on the meaning of SHOULD and MAY
(MUST seems pretty clear).

It almost seems that there is a need for a new level of recommendation
somewhere between SHOULD (which many people seem to take to mean "MUST
unless you have a good reason not to") and MAY (which some people take
to mean "may do if you choose to"). What is lacking (as I think Tim was
driving at) is a word to mean "we advise you to do this but don't want
to obligate you".

Obviously some of this confusion can be reduced if proper applicability
statements are used as described by Lars below.

For what its worth I am torn between options 2) and 3). Option 3) is
correct if the applicability is clearly defined to those TCPs where
there is significant risk of harm from these attacks

Toby
________________________________________________________________________
____
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473
648734 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: 25 September 2007 14:54
To: ext Joe Touch
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] tcpsecure: how strong to recommend?

Hi,

this brings up an important point we need to clarify. The tcpsecure
document contains a technical specification for multiple TCP mechanisms
to protect against certain attacks.

However, RFC 2026 recommends that technical specifications should also
come with a statement of applicability, i.e., something that says when
the technical specification should or should not be used.  
Many documents don't have this, and often that isn't an issue. The
tcpsecure document is missing this piece, too, but in this case I
believe this is causing some confusion.

For some folks, this lack of a clear applicability statement means that
the tcpsecure mechanisms become part of the "must-implement" set of TCP.
To other folks, the MUST/SHOULD/MAY in the current document
*are* a kind of applicability statement.

I think it would be helpful if we would tease apart applicability
statement and technical specification. What were missing is consensus on
the applicability of the proposed set of mechanisms. During the
discussion around this document, I've heard basically two choices being
expressed:

Whereas if the applicability is (2) or something else that is more
restricted than (1), a SHOULD is essentially without effect for stacks
that don't consider themselves to fall under the conditions stated.

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 11:13:58 -0700

Anantha Ramaiah (ananth) wrote:
> also could benefit from the proposed changes.

As an aside, it would be useful to provide in your doc an example of
such an application, e.g., where the endpoints and port numbers are
known or reasonably guessable.

> The TCP secure changes

The real point is that spoofing isn't a standalone thing. Putting
protections into TCP without locking down ICMP isn't sufficient, and
inferring authentication from header properties just narrows the window
of attack.

> up in mind after today's coffee :-)

If we agree that users should be able to choose the solution that fits,
let's go with MAYs all around.

Otherwise, aren't you dictating your solution as fitting everyone's needs?

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 26 Sep 2007 11:33:19 -0700

> > lived sessions like BGP. But there are many applications using TCP 
> > which also could benefit from the proposed changes.
> 
> As an aside, it would be useful to provide in your doc an 
> example of such an application, e.g., where the endpoints and 
> port numbers are known or reasonably guessable.

We can give it a thought about adding something if the WG feels so. I
for one feel that we would want to preserve the generic nature of this
document, you want to avoid listing application references as much as
possible, we can give examples but as you it wouldn't be a complete
list, anyways.

> 
> > The TCP secure changes
> > needs to be viewed as a standalone thing, since it focusses in 
> > providing robustness to TCP connections w.r.t some spoofing attacks.
> 
> The real point is that spoofing isn't a standalone thing. 
> Putting protections into TCP without locking down ICMP isn't 
> sufficient, and inferring authentication from header 
> properties just narrows the window of attack.

If we have to fix multiple layers, lets fix it, I have no problems. You
can do all at once or piecemeal, as simple as that. It doesn't matter
whether spoofing is standalone or not, it is about how well you can make
your TCP stack respond to such malicious attacks, if you care to do so.

> > different tools with varying degrees of complexity and 
> usage. A user 
> > can chose to use one of them depending on his/her requirements. 
> > Telling people to only use IPsec is akin to saying "always fly in 
> > business class". Yes I have used this analogy before, but 
> this is one 
> > whih popped up in mind after today's coffee :-)
> 
> If we agree that users should be able to choose the solution 
> that fits, let's go with MAYs all around.

I know you want all MAY's in place. Some others (includes me) are not
yet convinced that why SHOULD doesn't provide the same assurance.

> Otherwise, aren't you dictating your solution as fitting 

I am not "dictating" anything here. I am just supporting the reason why
I feel it should be SHOULD's :-) 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 11:44:28 -0700

...
> your TCP stack respond to such malicious attacks, if you care to do so.

TCP is not a secure protocol. It's not intended for protection from
malicious attacks per se; 'fixing' it is to assert your solution on
everyone, as below.

> I feel it should be SHOULD's :-) 

SHOULD dictates that everyone's TCP ought to have this included except
for specific good reason. MAY allows them to make the choice themselves.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 26 Sep 2007 11:58:02 -0700

> > If we have to fix multiple layers, lets fix it, I have no problems. 
> > You can do all at once or piecemeal, as simple as that. It doesn't 
> > matter whether spoofing is standalone or not, it is about 
> how well you 
> > can make your TCP stack respond to such malicious attacks, 
> if you care to do so.
> 
> TCP is not a secure protocol. It's not intended for 
> protection from malicious attacks per se; 'fixing' it is to 
> assert your solution on everyone, as below.

I see what you are saying except the "asserting your solution part". 

But you seem to equating some efforts of making TCP more robust to TCP
have an Ipsec like functionality, very far fetched, IMO.

Hmm... It boils to your favorite line of thinking : "Don't make any
robustness changes in TCP, just use IPsec", I thought we have beaten
that to death long time ago. :-)

Anyways, I don't want to side-track this discussion from it's original
intent viz., "strength of mitigations"

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 12:27:53 -0700

...
> intent viz., "strength of mitigations"

OK, so let's get back to that. If you believe that it's appropriate to
let people decide what mitigations they want to deploy, then why isn't
tcpsecure a MAY?

I.e., you MAY deploy it if you want the mitigations.

There's no MUST in that logic, any more than 'you MUST deploy
IPsec/BTNS/TCP-MD5++'.

I think we're all agreeing that "let the user decide" is appropriate.
What we disagree upon appears to be what that implies.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 26 Sep 2007 13:33:20 -0700

Inline comments....

> OK, so let's get back to that. If you believe that it's 
> appropriate to let people decide what mitigations they want 
> to deploy, then why isn't tcpsecure a MAY?

Here is why I think it is SHOULD ( I have already pointed out the
reasons, but will try to more explicit this time.)

- I believe by making it a SHOULD it already lets people chose. Many
implementations have ignored the recommendations tagged as SHOULD and
some of them "knobbed" it for the "good reasons" of their own.

- Like someone pointed out MAY is a weak statement, it could also imply
"MAY not". Why should it be a MAY when we know that the pros of the
soultion outweigh the cons?

- to me these recommendations are good to have, so it falls under SHOULD
since the internet has changed a lot from being what it was 20 years ago
and I believe protocol robustness and quality are good to have and esp.
for a pervasive protocol like TCP. To me "good to have" is a SHOULD. I
agree it is not "MUST have".

> There's no MUST in that logic, any more than 'you MUST deploy 

I am assuming it is a conditional MUST like "if you need security then
use TCP MD5", correct? Is "conditional MUST = SHOULD" ?

> What we disagree upon appears to be what that implies. 

Yes I think we are all focussed on the RFC language to be used here.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 15:20:07 -0700

...
> soultion outweigh the cons?

They do not in all cases. If TCP is deployed either where no well-known
connections exist, or where such connections are protected by other
authentication, this solution adds
	a) complexity
	b) chatter during valid RSTs
	c) IPR encumberance

> - to me these recommendations are good to have, 

You're now making decisions for others, i.e., these recommendations are
"good for everyone to have unless they have a reason not to". That's not
what you said before in terms of "let the user/implementer decide".

...
> use TCP MD5", correct? Is "conditional MUST = SHOULD" ?

It is a conditional SHOULD, i.e., a SHOULD with a caveat. From the
RFC2119-level, IMO that's a MAY with explanation.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 26 Sep 2007 16:29:27 -0700

> > - Like someone pointed out MAY is a weak statement, it could also 
> > imply "MAY not". Why should it be a MAY when we know that 
> the pros of 
> > the soultion outweigh the cons?
> 
> They do not in all cases. If TCP is deployed either where no 
> well-known connections exist, or where such connections are 
> protected by other authentication, this solution adds
> 	a) complexity

"complexity" and the strength of mitigation cannot be tied together,
IMO.

Almost every solution that tries to add/modify/delete some TCP behaviour
does add complexity to TCP processing.

That said, we have already debated in the past, about the so called
"complexity" of these solutions.

> 	b) chatter during valid RSTs

You mean an extra RTO? Ok, fair enough. But, benefits outweigh
drawbacks, I would think.

> 	c) IPR encumberance

AFAIK, this is not an issue as this was beaten to death before.

> You're now making decisions for others, i.e., these 
> recommendations are "good for everyone to have unless they 
> have a reason not to". That's not what you said before in 
> terms of "let the user/implementer decide".

"Good to have" since it improves TCP robustness and quality, this is my
viewpoint. This is different from "making decisions for others".

> It is a conditional SHOULD, i.e., a SHOULD with a caveat. 
> From the RFC2119-level, IMO that's a MAY with explanation.

Curious : Are you ok tagging the TCP secure mitigations with a
"conditional SHOULD" or "SHOULD with caveat" or "an applicability
statement with a SHOULD"? I am assuming that these are equivalent to MAY
with explanation? 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 16:56:24 -0700

> drawbacks, I would think.

FWIW, I mean *responding* to a RST.

> AFAIK, this is not an issue as this was beaten to death before.

It will remain the context under which a decision is made until IPR is
removed. Each party weighing in needs to decide how that impacts their
decision - and whether they want to impose it as a requirement on the
community.

> statement with a SHOULD"? I am assuming that these are equivalent to MAY

I'm saying that MAY with explanation is sufficient. There's no point in
a SHOULD unless you want to have the WG make a recommendation for
others. Even with context, this still amounts to forcing a solution. If
it's really all that useful and people aren't worried about the
complexity or IPR, they'll implement it. Let them decide.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Sep 2007 08:08:16 +0300 (EEST)

On Tue, 25 Sep 2007, Tim Shepard wrote:
...
> (I've not been following BTNS too closely recently).

I wouldn't expect to see measurable deployment within the next, say, 
5-10 years.

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2007 22:12:22 -0700

> I wouldn't expect to see measurable deployment within the next, say,

It's not clear whether BTNS would be used for BGP per se; network
managers may come to terms with the need for conventional IPsec and bite
the CA bullet anyway.

As to what will happen in 5-10 years, I'm not sure either, but I'll bet
money against any specific prediction either way. I haven't seen one
come true in 25 years.

Joe

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 13:01:42 -0400

[catching up]

> A point to note is that we neither obsolete nor update rfc793, so if we

I think this is wrong.  I think this document clearly updates 793.  It
says to do something differently from what 793 says and so I don't see
how you can say it does not somehow update that document.

allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 14:17:11 -0400

Anantha-

I have to say I am pretty drained from reading this thread and really
don't know if we have consensus on anything or are driving towards
developing it.

The one thing that really confuses me in this discussion is the
statements like this:

> Since, all these discussions about started due to TCP secure, let me
> use the same as an example. There is nothing wrong in making all
> mitigations SHOULD since the "very good reason" can be one of :-

It really seems to me that you are equating MAY and SHOULD.  It seems
like this is saying that implementers can come up with any reason to not
implement tcpsecure if we tag these with a SHOULD.  I think I understand
a number of other people's distinctions between MAY and SHOULD, but I
cannot figure out how you differentiate them and therefore I cannot
figure out why you think they ought to be SHOULD and not MAY.

allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 14:17:07 -0400

(Hat on.  I just talked to Ted about this and he is in agreement with
this request, but has not seen the text I am about to type ...)

It seems to me that this discussion is really divergent because there is
no applicability statement in the document, per Lars' comment.  I wonder
if you guys could go off and generate such a statement and then we could
re-visit this question.  I think that would factor things into a
question of "where" this is applicable and then how strongly we want to
advocate these mitigations within that context.  Is that reasonable?

Thanks,
allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 14:17:11 -0400

Anantha-

allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 14:17:07 -0400

Thanks,
allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 14:19:41 -0400

> So I ask: is BTNS succeeding such that it is a viable alternative to

The way I view the world here, this question is not particularly
germane.  This WG has taken on a work item to produce tcpsecure.  At
some point perhaps there will be a larger cross-area/WG discussion of
techniques to aid robustness in the face of spoofing and the IETF can
then puzzle through what we like and what we do not.  However, I don't
think this WG is going to make those sorts of decisions.

allman

---

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

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 11:17 AM
> To: Anantha Ramaiah (ananth)
> Cc: David Borman; Pekka Savola; [email-masked]; Fernando Gont
> (Hat on.  I just talked to Ted about this and he is in 
> agreement with this request, but has not seen the text I am 
> about to type ...)
> 
> It seems to me that this discussion is really divergent 
> because there is no applicability statement in the document, 
> per Lars' comment.  I wonder if you guys could go off and 
> generate such a statement and then we could re-visit this 
> question.  I think that would factor things into a question 
> of "where" this is applicable and then how strongly we want 
> to advocate these mitigations within that context.  Is that 
> reasonable?

Well, if the applicability statement is needed for making some forward
progress of the draft, then we need to do it. 

Is there any particular format which we are looking at? Lars's email, if
I remember correctly, also acknowledged the fact that not too many RFC's
in the past have had these sort of applicability statements in place. So
wondering any examples/ where to place one such ie., should it be a
separate section like "Security considerations" ?

-Anantha

---

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

> I have to say I am pretty drained from reading this thread 
> and really don't know if we have consensus on anything or are 
> driving towards developing it.

FWIW, the "majority vote" still stands at "2 SHOULDs and 1 MAY" ? So
there is some consensus, it appears.

> 
> The one thing that really confuses me in this discussion is 
> the statements like this:
> 
> It really seems to me that you are equating MAY and SHOULD.  

Sorry, I didn't mean to.

> It seems like this is saying that implementers can come up 
> with any reason to not implement tcpsecure if we tag these 
> with a SHOULD.  I think I understand a number of other 

Yes, my thinking was always been : since it isn't a MUST, SHOULD gives
that leeway. SHOULD gives the leeway that "you can chose not to
implement if you have some good reasons". I had pointed out the list of
reasons already. So are those reasons not "good enough" ?

> people's distinctions between MAY and SHOULD, but I cannot 
> figure out how you differentiate them and therefore I cannot 

My argument is simple, SHOULD gives a leeway and I think MAY is very
weak. As somone pointed out MAY is equated to "MAY NOT" esp, when the
recommendation is from a security viewpoint.

-Anantha

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 15:16:00 -0400

> progress of the draft, then we need to do it.

We are certainly open to suggestions from others on alternate ways to
proceed.  But, this seems like it will tease apart the issues so that
maybe we can make some progress.

> Is there any particular format which we are looking at? Lars's email,
> if I remember correctly, also acknowledged the fact that not too many
> RFC's in the past have had these sort of applicability statements in
> place. So wondering any examples/ where to place one such ie., should
> it be a separate section like "Security considerations" ?

My advice is to find an example.  I don't have one handy.  But, do
something reasonable so that the statement stands out.  I.e., make it a
(sub-)section or indent it under the words "applicability statement" or
whatever.  Just make sure we all know where it is without having to
guess.

allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 15:20:01 -0400

> there is some consensus, it appears.

Well... we don't work on "majority vote".  We work on consensus.  Ted
and I chatted a bit ago and I think it seems pretty clear to us that we
have no consensus on this issue.  15 people 'voted' in the meeting and a
few more people have voiced opinions on the list and even if one option
is 'winning' it certainly isn't doing so with something we are
comfortable calling even 'rough consensus' right now.  People can of
course argue that we're wrong.

allman

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Fri, 28 Sep 2007 16:55:42 -0700

> > > I have to say I am pretty drained from reading this thread and 
> > > really don't know if we have consensus on anything or are driving 
> > > towards developing it.
> > 
> Well... we don't work on "majority vote".  We work on 
> consensus.  Ted and I chatted a bit ago and I think it seems 
> pretty clear to us that we have no consensus on this issue.  
> 15 people 'voted' in the meeting and a few more people have 
> voiced opinions on the list and even if one option is 
> 'winning' it certainly isn't doing so with something we are 
> comfortable calling even 'rough consensus' right now.  People 
> can of course argue that we're wrong.

In the last meeting in Chicago, it was pointed out the only pending
issue is the "strength of the mitigations". 3 choices were listed,
people picked the choices ( Careful not to use the "vote" since you
don't seem to like it :-),
So I would think the next step is to pick on whichever choice comes up
as popular and move on. I for one don't see anything wrong with that
approach.

Atleast I am missing as to what would constitute a "rough consensus" ? 

-Anantha

---

From: Mark Allman <[email-masked]>
Date: Fri, 28 Sep 2007 20:23:53 -0400

> don't seem to like it :-), So I would think the next step is to pick
> on whichever choice comes up as popular and move on. I for one don't
> see anything wrong with that approach.
> 

First, it isn't me that doesn't like the word "vote".  It is the IETF
that doesn't take "votes".  Taking "votes" is problematic.  Take a look
at some of the IETF process documents, the Tao of the IETF, etc.  These
explain why there are not votes within the IETF and the rationale behind
the consensus process.

It seems to me that in this case it is clear that the WG is not
generally of one mind (i.e., come to consensus), with a non-trivial
number of folks wanting MAYs, SHOULDs and and/or some combination (via
picking some MAYs and some SHOULDs or using conditionals or whatever).
If you can show us that we're reading this wrong and that in fact these
folks are outliers then please do.

allman

---

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

> folks are outliers then please do.

FWIW, there is a separate concern - current positions represent a very
small set of participants. We are talking about modifications to 793 -
whether MAY or SHOULD - and those should not be taken on the consensus
of such a small sample as is currently weighing in.

Joe

---

From: "Mitesh Dalal \(mdalal\)" <[email-masked]>
Date: Sat, 29 Sep 2007 14:08:39 -0700

FWIW, I think we need to address the fundamentals first, as echoed by
Lars, Tim and your truly
some time back. i.e. are we labeling this changes as updates to rfc793 ?
Will we clearly state
(if the document proceeds to  standards track) to state "Updates: 793"
in the title of the document ?

OR

are we looking it as an additional protocol that can be added/embedded
to TCP (although there is no handshake to signal this understanding
between the TCP peers to distinctly picture this as an option,
but a small protocol nevertheless) and does not necessarily update the
base spec ? 

Once we hash this out, we can start the may/should/must nomenclature
consensus drive.

I may be the only voice that is unclear on this, but atleast we get to
hear how folks perceive this.

Mitesh

> Sent: Friday, September 28, 2007 5:24 PM
> First, it isn't me that doesn't like the word "vote".  It is 
> the IETF that doesn't take "votes".  Taking "votes" is 
> problematic.  Take a look at some of the IETF process 
> documents, the Tao of the IETF, etc.  These explain why there 
> are not votes within the IETF and the rationale behind the 
> consensus process.
> 
> It seems to me that in this case it is clear that the WG is 
> not generally of one mind (i.e., come to consensus), with a 
> non-trivial number of folks wanting MAYs, SHOULDs and and/or 
> some combination (via picking some MAYs and some SHOULDs or 
> using conditionals or whatever).
> If you can show us that we're reading this wrong and that in 
> fact these folks are outliers then please do.
> 
> allman
> 
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Sep 2007 14:20:37 -0700

> but a small protocol nevertheless) and does not necessarily update the

Whether this is a small change or not is irrelevant to whether it
updates TCP's rules for handling segments. All modifications to TCP
segment processing events update 793 - whether they are standards track
or experimental.

An "additional protocol" could not change any TCP headers, TCP endpoint
state, *or* TCP segment handling events.

I remain confused at this sort of question coming up at all. If this is
not a change to TCP, at the very least it is being discussed in the
wrong working group.

Joe

---

From: Mark Allman <[email-masked]>
Date: Sat, 29 Sep 2007 20:59:55 -0400

Hat off ... personal opinion ...

> i.e. are we labeling this changes as updates to rfc793 ?  Will we
> clearly state (if the document proceeds to standards track) to state
> "Updates: 793" in the title of the document ?
> 
> OR
> 
> between the TCP peers to distinctly picture this as an option, but a
> small protocol nevertheless) and does not necessarily update the base
> spec ?

I cannot understand how this can be viewed as 'an additional protocol'.
That seems nonsensical to me.  To my way of thinking the mitigations in
the tcpsecure document **change** the previously specified response to
certain packets and therefore tcpsecure is necessarily an **update**.
Maybe its just me ...

allman