[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IKEv2 changes (was Re: Issue #76: TFC padding in ESPv3 and requirments for IKEv2)



> When I last spoke with Russ, he indicated that he was prepared to 
> tolerate another delay on the IKE v2 document to incorporate ...
> IF he still feels this way, then ...

There are a few other items, most of which have been mentioned at one
time or another, that I think need to be incorporated into the IKEv2 doc.

Please add text saying how the ICMP Type and Code are encoded into the
16-bit "port" field -- Type in the the most significant 8 bits and
Code in the least significant 8 bits; and text saying that the
Mobility Header Type should be in the most significant 8 bits and the
least significant 8 bits should be 0 for the "start" field of the
range and 255 for the "end" field).

Please add text saying that OPAQUE is encoded by setting a "start"
field to the maximum value and the "end" field to the minimum value.

I think that there should be text describing how unidirectional
policies should be encoded in the current syntax.  The immediate
examples are ICMP and the Mobility Header. I would suggest saying that
the ICMP sender's end should specify the Type and Code in the
"initiator's" traffic selectors, and that they should be "OPAGUE" in
the "responder's".

I think that the 2401bis model is for non-initial fragments to be
placed into a "fragment-only" SA.  If so, please add text to IKEv2
saying that IPv4 non-initial fragments should be mapped to protocol 44
(IPv6 Fragmentation Header).

If we will be supporting SAs for non-initial fragments at the level of
protocol, e.g., TCP fragments get a different SA than UDP fragments,
then the fragmentation "protocol" would need to have "ports" that is
the value of the IPv4 protocol field or IPv6 Fragmentation Header's
Next Header field.  The 8-bit protcol number should be encoded right
justivfied in the port field (i.e., the most significant 8 bits should
be zero). If the WG thinks that this is reasonable, then the IKEv2
and/or 2401bis should describe it.

Charlie