Subject: [Ipsec] Results of the Straw Poll re: Fragmentation handling

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 02 Jun 2004 14:49:53 -0400

The results of the straw poll indicated that out of 16 responses,
roughly twice as many contributors (11) preferred that Methods #2 and #3
be a MAY implement, over thouse who preferred that at least one of
Methods #2 and #3 be a SHOULD or a MUST (5).

There was also a somewhat surprising number (albeit a minority)
who registered a strong dislike of Method #2 --- four or five
respondents indicated that they thought Method #2 should be a MUST NOT.

Hence, it seems that we have a rough consensus within the working group
that both Method #2 and #3 should both be MAY.  To accomodate those who
dislike Method #2, I would propose that if we can get someone from that
camp to write a paragraph detailing their objections to mixing
non-initial fragments when initial fragments are not mixed, it would
seem to me reasonable to record the minority dissent in the architecture
specification.

						- Ted

Yoav Nir
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Tero Kivnen
	1.  SHOULD/MUST
	2.  MAY
	3.  SHOULD

Scott G. Kelly
	1.  SHOULD/MUST (for 3 only)
	2.  MUST NOT
	3.  SHOULD

Michael Roe
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Yougui Cheng
	1.  MAY / MAY
	2.  SHOULD NOT
	3.  MAY

Mark Duffy
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Niklas Hallqvist
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Srini
	1.  SHOULD / MUST
	2.  MAY
	3.  SHOULD

Satoshi Inoue
	1.  MAY /  MAY
	2.  MAY
	3.  MAY

Valery Smyslov
	1.  SHOULD / MUST
	2.  MAY
	3.  SHOULD

Paul Hoffman
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Bora Akyol
	1.  MAY  / MAY
	2.  MAY
	3.  MAY

Joe Tardo
	1.  SHOULD / MUST (3 should be MUST)
	2.  MAY
	3.  SHOULD

Markku Savela
	1.  MAY / MAY
	2.  MUST NOT
	3.  MAY

Mika Joutsenvirta
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Joe Touch
	1.  MAY / MAY (2 MUST NOT)
	2.  MUST NOT
	3.  MAY

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 03 Jun 2004 09:51:29 -0700

Hi Ted,

I'm a little surprised at your assessment of my position on question

Here's what I said for #2:
> NONE of the above - why even mention this? I doubt there are many
> 100% compliant implementations for the first round of ipsec, and find
> it highly unlikely that this will change. Implementations that don't
> care about fragment security probably don't care about port/protocol
> differentiation. The two seem incompatible and unlikely. I can't
> believe we've wasted so much time/energy on this.

I'm sorry that this was unclear. What I meant to say was, why even 
mention this in the draft at all - why make it an option? I guess my 
point was that if folks want to implement special handling for special 
cases, history has demonstrated that they will do so whether they have 
special dispensation or not. It may not make sense to complicate the 
spec for (what I perceive to be) a very small minority of implementations.

That's not a clear selection of one of the terms you asked for, but it's 
definitely not a MUST NOT. I guess I should have used the RFC2119 
language, in which case I might say "SHOULD NOT", meaning someone that 
really knows what they are doing might have justification, but this 
should not be casually undertaken. I think the current draft rev gives 
cautions for ipv6, but we might want similar cautions for ipv4.

The primary assumption underlying a fragment-only SA is that the other 
end can be trusted to only put allowable data into the tunnel. 
Sometimes this assumption is justified, but this is certainly not always 
the case. Hence, this assumption must be evaluated prior to implementing 
a fragment-only tunnel.

As an aside, I wonder if anyone requiring such a thing in practice 
wouldn't be better off to simply "tunnel-all" over a single SA pair.

--Scott

Theodore Ts'o wrote:

> roughly twice as many contributors (11) preferred that Methods #2 and
> #3 be a MAY implement, over thouse who preferred that at least one of
> There was also a somewhat surprising number (albeit a minority) who
> registered a strong dislike of Method #2 --- four or five respondents
> indicated that they thought Method #2 should be a MUST NOT.
> 
> Hence, it seems that we have a rough consensus within the working
> group that both Method #2 and #3 should both be MAY.  To accomodate
> those who dislike Method #2, I would propose that if we can get
> someone from that camp to write a paragraph detailing their
> objections to mixing non-initial fragments when initial fragments are
> not mixed, it would seem to me reasonable to record the minority
> dissent in the architecture specification.
> 
> - Ted
> 
> 
> Yoav Nir 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Tero Kivnen 1.  SHOULD/MUST 2.  MAY 3.  SHOULD
> 
> Scott G. Kelly 1.  SHOULD/MUST (for 3 only) 2.  MUST NOT 3.  SHOULD
> 
> Michael Roe 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Yougui Cheng 1.  MAY / MAY 2.  SHOULD NOT 3.  MAY
> 
> Mark Duffy 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Niklas Hallqvist 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Srini 1.  SHOULD / MUST 2.  MAY 3.  SHOULD
> 
> Satoshi Inoue 1.  MAY /  MAY 2.  MAY 3.  MAY
> 
> Valery Smyslov 1.  SHOULD / MUST 2.  MAY 3.  SHOULD
> 
> Paul Hoffman 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Bora Akyol 1.  MAY  / MAY 2.  MAY 3.  MAY
> 
> Joe Tardo 1.  SHOULD / MUST (3 should be MUST) 2.  MAY 3.  SHOULD
> 
> Markku Savela 1.  MAY / MAY 2.  MUST NOT 3.  MAY
> 
> 
> Mika Joutsenvirta 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Joe Touch 1.  MAY / MAY (2 MUST NOT) 2.  MUST NOT 3.  MAY
> 
> 
> 
> _______________________________________________ Ipsec mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Joe Touch <[email-masked]>
Date: Fri, 04 Jun 2004 14:55:12 -0700

Scott G. Kelly wrote:

> mention this in the draft at all - why make it an option? 

I agree - even mentioning it just confuses things. There are no other 
cases where packets from a single SPI entering on a single interface 
with the same addresses and ports are handled by different SPD entries.

I can't imagine why anyone would think separating the two would be a 
good thing, and if the policies are different, a dangerous thing.

...
> cautions for ipv6, but we might want similar cautions for ipv4.

Anyone who wants to violate a spec can do so at their own peril. The 
MUST NOT would be to suggest this is a dangerous thing, with otherwise 
uncontrolled consequences. IMO, if it's mentioned at all, it is 
definitely MUST NOT.

Joe