Subject: [IPsec] Issue #63: Position of arbitrary notify payloads

From: Yaron Sheffer <[email-masked]>
Date: Wed, 1 Apr 2009 23:37:56 +0300

Yaron:

Appendix C: please also mention extension notifications [N+], other than in
C.6.

Paul:

Maybe copy it everywhere like we have [V+]

Not discussed in SF.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Apr 2009 15:55:13 +0300

> Maybe copy it everywhere like we have [V+]

That is ok for me.

Btw, is there any reason why [V+] is not listed in the IKE_AUTH
excghange with EAP in the intermediate EAP messages and final AUTH
request from the initiator?
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Apr 2009 17:41:33 -0700

>request from the initiator?

We could add it, but I think that would surprise some implementers. Is it really needed?

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Apr 2009 12:18:23 +0300

> We could add it, but I think that would surprise some implementers.

I do not think any of the [V+] payloads are really needed, as section
3.12 clearly says that "A Vendor ID payload may be sent as part of any
message.".

My question was more of "was this omission trying to say something".
I.e. does that it is NOT listed in that those messages trying to say
that those messages are not logical place for vendor ID payloads. (I
actually only now noticed the text about most logical place). 

I would at least expect that vendor ID payloads could be also used in
the last AUTH message from client to server, i.e. after the EAP
authentication is finished. The server is already marked so that it
can use [V+] in its last response. I.e. for server the logical places
are first and last response, but for client the only logical place
listed is the first request, last request was ommitted.

I agree that during the EAP exchanges itself (the ones repeted 1..N
times) the vendor ID payloads might not be that logical (as most
likely all extensions during that is done inside the EAP messages
itself, not as IKEv2 vendor ID payloads).

But I think the last request is bit different case, and I myself
consider that as one that could be logical place for vendor ID
payload for some extension.

Currently it is bit funny that only places where vendor ID payloads
are not supposed to be most logical are:

  - IKE_AUTH exchange with EAP: EAP payload request
  - IKE_AUTH exchange with EAP: EAP payload response
  - IKE_AUTH exchange with EAP: last request from client
  - CREATE_CHILD_SA for Child SA: generic error case response
  - INFORMATIONAL exchange: request
  - INFORMATIONAL exchange: response

It is not very "most logical" locations if it is listed in 71% of
cases (i.e. 15 packets out of 21).

I think the most logical place currently to send those vendor ID
payloads is only during IKE_SA_INIT exchange request, and IKE_SA_INIT
exchange normal response.

We currently do not have any extensions which would send them in any
other locations, and I have not seen any implementations sending them
in any other locations yet. If you want to pick the "most logical"
place, then I would only put it on those exchanges, and say that they
can still be part of any other message too if needed. 
-- 
[email-masked]