Re: CONSENSUS TEST: Fragmentation handling

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> >   I'm unclear how a responder knows that a non-initial fragment SA is
> >being negotiated in IKE. Is it based only on the OPAQUE value as
> >port-selectors? What about the protocol?
> 
> The use of OPAQUE is now restricted to carriage of non-initial 
> fragments, after the change that Mark suggested. so, yes, negotiating 
> an SA with port fields set to OPAQUE indicates that the SA is used to 
> carry non-initial fragments. for IPv4, this is irrespective of the 
> port field selector, which could be specific, or ANY.  for v6, it is 
  ^^^^^^^^^^

I assume this should be "protocol field selector", not "port"


> conceivable that the next protocol would not be identified in the 
> initial fragment, so one would have to set protocol to ANY in that 
> case.
> 
> >
> >     Theodore> 3. An implementation SHOULD support some form of stateful
> >     Theodore> fragment checking for a tunnel mode SA with non-trivial
> >     Theodore> port field values (not ANY or OPAQUE).  Implementations
> >     Theodore> that will transmit non-initial fragments on a tunnel mode
> >     Theodore> SA that makes use of non-trivial port selectors MUST
> >     Theodore> notify a peer via an IKE payload (TBD). The peer MUST
> >   This seems like a new option to the TSx payload, right?
> right.

We have to think how to negotiate all of these in the IKEv2, but first
I think we need to get agreement on that we are really going to accept
the base proposal (I hope we have that agreement now).

So we have 3 different things to negotiate:

	1) All traffic through one SA regardless of ports
	2) First-fragments on per port SAs, and non-first on one special SA
	3) First-fragments and non-first fragments on per port SAs

The case 1 is simple,

1)	PROTO = ANY or xx
	PORT = ANY <-> ANY

Case 2 is little more complicated:

	First-fragments SAs:

2a)	PROTO = xx
	PORT = yy <-> zz

	Special non-first fragment SA:

2b)	PROTO = ANY or xx
	PORT = OPAQUE <-> OPAQUE

Case 3 SAs looks identical to the First-fragment SAs in case 2:

3)	PROTO = xx
	PORT = yy <-> zz

so we need some method to distinguish the SAs in cases 2a and 3, and
make sure that if the negotiation fails we can fall back properly.

One option is to add new notify to case 3, i.e. something like
NON_FIRST_FRAGMENTS_ALSO notification. This notification would tell
that the sender would like to send also non-first fragments inside
this SA.

If both ends send this notification then we are using case 3. If only
one end sends it then we are using case 2, and the initiator should
then create the 2b SA. If initiator does in that case want to fall
back to case 1, it will delete the SA and create new SA for case
1.
-- 
kivinen@safenet-inc.com