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

From: Mark Allman <[email-masked]>
Date: Mon, 01 Oct 2007 08:47:30 -0400

Hyperbole elided, but still trying to understand ...

> but
> saying that "SHOULD doesn't give leeway not to do something", is
> something which I would want to dis-agree.

If tcpsecure is a SHOULD then what would be an invalid reason for me to
exclude it from my implementation?

allman

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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 1 Oct 2007 09:23:09 -0700

> If tcpsecure is a SHOULD then what would be an invalid reason 
> for me to exclude it from my implementation?

It is difficult to say since the implementer is given the choice whether
or not to include/exclude it. Yes, both SHOULD and MAY provides that
luxury. The only difference is the strength of the advise offered by
both these adjectives which needs to be viewed from a recommendation
perspective. If you think that these are generally good to have then use
SHOULD else these are really optional ones use MAY. The bottomline is
that unless it is tagged as MUST, I believe we have already given the
flexibility, the key is how "strong" we would want to recommend and that
is what we are trying to do and get the consensus. Atleast this *my
understanding*. I expressed my opinion and other have expressed theirs. 

Also, I am trying to understand something here since I wasn't sure how
situations like this have been dealt in the past. Actually, I am trying
to understand the algorithm used to arrive consensus here?. I was
assuming that after the "hums were sought" and the email was sent both
offering 3 choices, now after getting the responses the next step would
be to derive something out of that once we have reached enough responses
or a stipulated time expires if one exists. If we believe there isn't
even a rough consensus after the responses so far, what is the next
step? Curious.

-Anantha

---

From: Mark Allman <[email-masked]>
Date: Mon, 01 Oct 2007 12:34:02 -0400

> If we believe there isn't

Per my previous email:

  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?

(From which my understanding was that you guys were going to generate
said statement.)

allman

---

From: "Edward A. Gardner" <[email-masked]>
Date: Mon, 01 Oct 2007 12:15:31 -0600

I normally just lurk here silently, and I certainly wasn't at Chicago or 
any of the other meetings discussing this.  But it strikes me that people 
are getting caught up in language problems and losing sight of what is 
desired.  In particular there is confusion between discussing whether 
implementing tcpsecure itself is mandatory / recommended / optional vs. 
whether some feature of tcpsecure is mandatory / recommended / optional, 
given that tcpsecure itself is implemented.

Clearly there will be implementations that do not implement 
tcpsecure.  Historical implementations.  Those that achieve similar ends 
through different means (e.g. IPSEC, MD5) and therefore have no need or use 
for tcpsecure.

Clearly there are implementations that need or want tcpsecure, BGP being 
the prominent example.

So there are two implementation variations that we consider necessary.  Is 
there any need or point in more?  Remember that compatibility problems, 
testing, etc. scale as (at least) NxN.  There is enormous practical 
incentive to minimize the number of variations that are implemented and 
deployed.

I contend that the specifications or RFCs should allow exactly two 
variations.  Those implementations that ignore and do not implement 
tcpsecure at all.  And those that implement all of it.

I think the way to accomplish that is to include an applicability statement 
saying that implementing tcpsecure is optional.  An implementation MAY or 
MAY NOT implement it.  And giving guidance on when one should or should 
not.  Probably something along the lines of saying one should implement it 
unless the same ends are accomplished by other means, and giving several 
examples of other means.

But if an implementation does choose to implement tcpsecure, then it MUST 
implement all of it -- the features, protocol behavior, etc. are described 
in the RFC using MUST.  Conversely, if an implementation chooses not to 
implement tcpsecure, then it MUST NOT implement any part of it.  Either 
implement all of tcpsecure or none of it.  Yes, this requires careful 
phrasing, but it can be done.

I am assuming that all the features included in tcpsecure are considered 
necessary or desirable for BGP.  If any are not, shouldn't they be excluded 
on the grounds that no one is ever likely to implement them?

One might contemplate the impact of the IETF requirement for independently 
developed, interoperable implementations.  The three tcpsecure (three 
choices of MAY vs. SHOULD that are being discussed) interact to some 
degree.  If each are described using MAY or SHOULD, we get eight 
implementation variations.  Each needing two independent implementations 
means at least sixteen implementation, which is absurd.  Does anyone really 
want to allow some arguably ill-informed implementors to pick and choose, 
as opposed to saying all or none?  Isn't it our responsibility as 
architects (who claim to know what we are doing :-) to minimize variations, 
not unnecessarily expand them?

Caveat: my primary experience is with the T10 and T11 standards (SCSI and 
friends), I apologize for my errors with IETF terminology and practice.

Dropping back into my hole to resume lurking.

Edward A. Gardner               eag at ophidian dot com
Ophidian Designs                719 593-8866
1262 Hofstead Terrace
Colorado Springs, CO  80907

---

From: "Mitesh Dalal (mdalal)" <[email-masked]>
Date: Mon, 1 Oct 2007 14:55:24 -0700

well said Edward! I concur with your take on this and was alluding to
the same ideas that you mentioned below. To highlight your comment
again:

> In particular 
> there is confusion between discussing whether implementing 
> tcpsecure itself is mandatory / recommended / optional vs. 
> whether some feature of tcpsecure is mandatory / recommended 
> / optional, given that tcpsecure itself is implemented.

I think it does captures the debate we are having here. My
opinion is that if we view these changes as Updates to RFC793, then
they may be perceived as mandatory changes and again open discussions
around IPR, MAY/SHOULD/MUST language and so on. However if we have
a  banner statement stating that implementing these changes are
recommended/optional and enumerate situations in which they are 
helpful this should alleviate a lot of opposing view.  And
once we have this statement and if a tcp implementation does decide
to have this feature then it MUST be this way for the feature to work
correctly.

So to reiterate to the group, we need an applicability statement that
highlights the implementations/deployments/applications that are
RECOMMENDED to have this fix, with others being OPTIONAL. However,
the features/changes themselves being MUST (or SHOULD, if that's what
it would take for a consensus). Is the group in agreement here?

my 0.02
Mitesh

> -----Original Message-----
> From: Edward A. Gardner [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 11:16 AM
> To: [email-masked]
> Subject: Re: [tcpm] tcpsecure: how strong to recommend? 
> 
> I normally just lurk here silently, and I certainly wasn't at 
> Chicago or any of the other meetings discussing this.  But it 
> strikes me that people are getting caught up in language 
> problems and losing sight of what is desired.  In particular 
> there is confusion between discussing whether implementing 
> tcpsecure itself is mandatory / recommended / optional vs. 
> whether some feature of tcpsecure is mandatory / recommended 
> / optional, given that tcpsecure itself is implemented.
> 
> tcpsecure.  Historical implementations.  Those that achieve 
> similar ends through different means (e.g. IPSEC, MD5) and 
> therefore have no need or use for tcpsecure.
> 
> Clearly there are implementations that need or want 
> tcpsecure, BGP being the prominent example.
> 
> So there are two implementation variations that we consider 
> necessary.  Is there any need or point in more?  Remember 
> that compatibility problems, testing, etc. scale as (at 
> least) NxN.  There is enormous practical incentive to 
> minimize the number of variations that are implemented and deployed.
> 
> I contend that the specifications or RFCs should allow 
> exactly two variations.  Those implementations that ignore 
> and do not implement tcpsecure at all.  And those that 
> implement all of it.
> 
> I think the way to accomplish that is to include an 
> applicability statement saying that implementing tcpsecure is 
> optional.  An implementation MAY or MAY NOT implement it.  
> And giving guidance on when one should or should not.  
> Probably something along the lines of saying one should 
> implement it unless the same ends are accomplished by other 
> means, and giving several examples of other means.
> 
> But if an implementation does choose to implement tcpsecure, 
> then it MUST implement all of it -- the features, protocol 
> behavior, etc. are described in the RFC using MUST.  
> Conversely, if an implementation chooses not to implement 
> tcpsecure, then it MUST NOT implement any part of it.  Either 
> implement all of tcpsecure or none of it.  Yes, this requires 
> careful phrasing, but it can be done.
> 
> 
> I am assuming that all the features included in tcpsecure are 
> considered necessary or desirable for BGP.  If any are not, 
> shouldn't they be excluded on the grounds that no one is ever 
> likely to implement them?
> 
> One might contemplate the impact of the IETF requirement for 
> independently developed, interoperable implementations.  The 
> three tcpsecure (three choices of MAY vs. SHOULD that are 
> being discussed) interact to some degree.  If each are 
> described using MAY or SHOULD, we get eight implementation 
> variations.  Each needing two independent implementations 
> means at least sixteen implementation, which is absurd.  Does 
> anyone really want to allow some arguably ill-informed 
> implementors to pick and choose, as opposed to saying all or 
> none?  Isn't it our responsibility as architects (who claim 
> to know what we are doing :-) to minimize variations, not 
> unnecessarily expand them?
> 
> Caveat: my primary experience is with the T10 and T11 
> standards (SCSI and friends), I apologize for my errors with 
> IETF terminology and practice.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Oct 2007 16:13:42 -0700

Mitesh Dalal (mdalal) wrote:
> correctly.\

I think we agree that there are two levels of language needed:

1) for the entire system
	for which I think MAY is appropriate,
	and the conditions when useful would be beneficial to note

2) for the components, once you decide to implement
	MUST/MAY/SHOULDs as needed there. there seem like there are
	a few MAYs for various parts, MUSTs for others;
	it's not all MUSTs, but I don't think there will be
	deep discussions about this

Joe

---

From: Lars Eggert <[email-masked]>
Date: Tue, 2 Oct 2007 09:19:21 +0300

On 2007-10-1, at 19:23, ext Anantha Ramaiah (ananth) wrote:
> or not to include/exclude it.

RFC2026 says:

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.

Some in the IESG have argued that "(...) implications must be  
understood and carefully weighed" means that drafts needs to  
explicitly discuss under what conditions it is OK to disregard a  
SHOULD ("choosing a different course.")

Obviously, few drafts do this. But because we're hung up on what to  
do with this particular draft, following RFC2026 more closely might  
help us make progress.

Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 2 Oct 2007 08:57:22 -0700

> So to reiterate to the group, we need an applicability 
> statement that highlights the 
> implementations/deployments/applications that are RECOMMENDED 
> to have this fix, with others being OPTIONAL. However, the 
> features/changes themselves being MUST (or SHOULD, if that's 
> what it would take for a consensus). Is the group in agreement here?

++; 
(with the author hat off :-)

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Oct 2007 09:12:07 -0700

> (with the author hat off :-)

As a way forward, the following captures the SHOULD/SHOULD/MAY which was
 most supported in Chicago:

---------------------------------------------------------------------------

tcpsecure SHOULD be implemented in TCP stacks supporting router.
Notable exceptions include deployments where routers are known to use
other antispoofing protection, e.g., IPsec, TCP/MD5 and its successors.

tcpsecure MAY be implemented in other TCP stacks.

----
within tcpsecure:

RST protection MUST be supported

SYN protection MUST be supported

data segment (i.e., non-RST, non-SYN) protection MAY be supported

-------------------------------------------

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 2 Oct 2007 09:45:27 -0700

> data segment (i.e., non-RST, non-SYN) protection MAY be supported

I think you got it wrong. 

Most supported in Chicago was about [SHOULD/SHOULD/MAY] WITHOUT the
applicability statement in place. It was "STANDALONE" question raised by
the chairs for which the consensus seemed to be in favour of S/S/M.  Now
WITH the applicability statement in place, it completely changes the
entire equation. To quote Mark's email :

BEGIN QUOTE
> 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
> want to advocate these mitigations within that context.  Is that
END QUOTE

So, the game plan moving forward is, to generate the AS and revisit the
mitigation strengths. Also, just in case you missed, some of responses
in this list have indicated no issues with "MUST'ing" all the
mitigations provided there is a proper applicability statement in place.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Oct 2007 13:29:06 -0700

Notes below....

Anantha Ramaiah (ananth) wrote:
> applicability statement in place.

Agreed. I was trying to capture Chicago in the bottom portion.

> It was "STANDALONE" question raised by
> entire equation. 

I don't think it does. Even with a qualified SHOULD on the overall set,
data segment protection is still a MAY. What it changes is the SHOULDs
on the RST and SYN to MUSTs, to say that you shouldn't implement one or
the other as desired *if* you decide to implement the set.

...
> mitigation strengths. 

I tried to do that above.

> Also, just in case you missed, some of responses

I know - that was one of the set discussed. OK, so here's what I'm
specifically asking:

1) is the AS above reasonable?

2) regarding the RST/SYN/data components:
	- are the MUST/MUST/MAY above reasonable?
	- Or should they be SHOULD/SHOULD/MAY?
	- or something else

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 2 Oct 2007 14:40:50 -0700

Pl see inline comments...
 
> >> tcpsecure MAY be implemented in other TCP stacks.

<snip>

> 
> > It was "STANDALONE" question raised by the chairs for which the 
> > consensus seemed to be in favour of S/S/M.  Now WITH the 
> applicability 
> > statement in place, it completely changes the entire equation.
> 
> I don't think it does. Even with a qualified SHOULD on the 
> overall set, data segment protection is still a MAY. What it 
> changes is the SHOULDs on the RST and SYN to MUSTs, to say 
> that you shouldn't implement one or the other as desired *if* 
> you decide to implement the set.

I dis-agree. All the reasoning so far with the "chosen" adjectives for
the individual mitigations are without the applicability statement in
place.
<snip>

> 
> > Also, just in case you missed, some of responses in this list have 
> > indicated no issues with "MUST'ing" all the mitigations 
> provided there 
> > is a proper applicability statement in place.
> 
> I know - that was one of the set discussed. OK, so here's 
> what I'm specifically asking:
> 

Well, I (some others also pointed out) wouldn't mention router, since
these mitigations can be/are used in devices not routers per se. But we
can use this text as a reference for generating the AS. Others may want
to comment here as well.

> 	- Or should they be SHOULD/SHOULD/MAY?

Something else. To me, all the mitigations are equally important and
hence they  classified as MUST after the AS is in place.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Oct 2007 14:50:32 -0700

> can use this text as a reference for generating the AS. Others may want

Can you suggest a term that's useful? How about something specific:

"Devices with services where both endpoints are typically known, e.g.,
BGP."

> hence they  classified as MUST after the AS is in place.

OK, so here are some options:

	a) MUST/MUST/MUST
	b) MUST/MUST/SHOULD
	c) MUST/MUST/MAY

I don't quite understand why we would go with SHOULD for either RST or
SYN individually; if anyone can, it'd be useful to make the case. We can
mark Anantha as being in favor of (a). I would interpret the WG as
*probably* being in favor of (c), since if data was a MAY unqualified,
then at best it's a MAY qualified, BUT I'm not trying to make that case
myself.

I prefer (c), but that's just my individual perspective. I wouldn't care
much which of a-c is used.

Joe