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

["Scott G. Kelly" <scott at airespace.com>]

Hi Ted,

I'm a little surprised at your assessment of my position on question
#2, so I think I must have been unclear.  Here's your summary:

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

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:

> 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 
> Ipsec at ietf.org https://www1.ietf.org/mailman/listinfo/ipsec


_______________________________________________
Ipsec mailing list
Ipsec at ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec