Issue 30: Protocol ID in notifications

Tero Kivinen wrote:
> > 3.  Payload formats
> > 
> > 3.1  MOBIKE_SUPPORTED notification payload
> > 
> >    The MOBIKE_SUPPORTED notification payload is included in
> >    the IKE_SA_INIT messages to indicate that the implementation
> >    supports this specification.
> > 
> >    The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA
> >    (16396..40959).  The Protocol ID field is set to one (1), and
> >    SPI Size is set to zero.  There is no data associated with 
> >    this Notify type.
<snip>
> Also I think this notify does not relate to existing SA, so the
> protocol ID should be 0.
>
> > 3.2  ADDITIONAL_ADDRESS notification payload
<snip>
> Also I think this notify does not relate to existing SA, so the
> protocol ID should be 0.

Hmm... IKEv2 is not very clear on that part. There are some
notifications that are clearly about existing ESP/AH SAs, but in
some sense all the other notifications are (loosely) related to 
the IKE_SA. Draft-eronen-ipsec-ikev2-clarifications-03 also has 
text about this:

> 6.10  Protocol ID/SPI fields in Notify payloads
>
>   Section 3.10 says that the Protocol ID field in Notify
>   payloads "For notifications which do not relate to an
>   existing SA, this field MUST be sent as zero and MUST be
>   ignored on receipt".  However, the specification does not
>   clearly say which notifications are related to existing SAs
>   and which are not.
>
>   Since the main purpose of the Protocol ID field is to
>   specify the type of the SPI, our interpretation is that the
>   Protocol ID field should be non-zero only when the SPI field
>   is non-empty.
>
>   There are currently only two notifications where this is the
>   case: INVALID_SELECTORS and REKEY_SA.

The text above would seem to imply that Protocol ID 1 is never
used in notifications, so MOBIKE should also use ID 0.
This is OK with me..

(Do you agree with the text in the clarifications draft?)

Best regards,
Pasi