pasi.ero...@nokia.com writes:
> - Section 5: Peer vendor IDs cannot be "implementation specific" -- if
> the old gateway sent Vendor ID "FOO", the client has to unambiguously
> know whether it's allowed to FOO vendor-specific payloads to the new
> gateway or not. Probably this should be "Not resumed, Vendor ID
> payloads are resent in new exchange if required".
As we are resuming back to the same GW (failover from one GW to
another was specific non-goal for this document), I think we can
safely assume that GW support exactly same vendor IDs which it did
last time we connected it (or if the GW version was changed and
support for some vendor IDs were removed, then resumption tickets were
also invalidated).
So in this case the "implementation specific" is quite ok. I.e if
server and client support extension "FOO" indicated by vendor ID
"FOO", which requires some external data to be stored, then that
information that "FOO" was supported and that information was stored
to ticket needs to be stored to ticket.
If the extension "FOO" does not need any data to be stored across the
resumptions, then there is no need to modify ticket, thus there is not
really need to store information whether "FOO" was supported in the
first place or not.
Then there is this second case whether client is allowed to "remember"
that gateway supported extension "FOO" without sending any Vendor ID
payloads, or whether they need to be resent. I think we should require
them to be resent, as you said there.
But there is still cases where ticket might need to store extra
information depending whether vendor ID was originally used or not.
So I think we need two separate cases one for "Supported Vendor IDs"
which is "Not resumed, Vendor ID payloads are resent in new exchange
if required", and some kind of "Vendor ID specific data", which is
"Implementation specific (needed in ticket only, if vendor-specific
state is required)".
BTW, the table would be much more readable if there would be some kind
of separators between items, i.e. change to be:
+------------------------------------+------------------------------+
| State Item | After Resumption |
+------------------------------------+------------------------------+
| IDi | From the ticket (but must |
| | also be exchanged in |
| | IKE_AUTH). See also Note 1 |
+------------------------------------+------------------------------+
| IDr | From the ticket (but must |
| | also be exchanged in |
| | IKE_AUTH) |
+------------------------------------+------------------------------+
| Authentication method (PKI, | From the ticket |
| pre-shared secret, EAP, PKI-less | |
| EAP | |
| [I-D.eronen-ipsec-ikev2-eap-auth] | |
| etc.) | |
+------------------------------------+------------------------------+
| Certificates (when applicable) | From the ticket, see Note 2 |
+------------------------------------+------------------------------+
| Local IP address/port, peer IP | Selected by the client, see |
| address/port | Note 3 |
+------------------------------------+------------------------------+
| NAT detection status | From new exchange |
+------------------------------------+------------------------------+
| SPIs | From new exchange, see Note |
| | 4 |
+------------------------------------+------------------------------+
| Which peer is the "original | Determined by the initiator |
| initiator"? | of IKE_SESSION_RESUME |
+------------------------------------+------------------------------+
| IKE SA sequence numbers (Message | Reset to 0 in |
| ID) | IKE_SESSION_RESUME, and |
| | subsequently incremented |
| | normally |
+------------------------------------+------------------------------+
| IKE SA algorithms (SAr) | From the ticket |
+------------------------------------+------------------------------+
| IKE SA keys (SK_*) | The old SK_d is obtained |
| | from the ticket and all keys |
| | are refreshed, see |
| | Section 5.1 |
+------------------------------------+------------------------------+
| IKE SA window size | Reset to 1 |
+------------------------------------+------------------------------+
| Child SAs (ESP/AH) | Created in new exchange, see |
| | Note 7 |
+------------------------------------+------------------------------+
| Internal IP address | Not resumed, but see Note 5 |
+------------------------------------+------------------------------+
| Other Configuration Payload | Not resumed |
| information | |
+------------------------------------+------------------------------+
| Peer vendor IDs | Implementation specific |
| | (needed in the ticket only |
| | if vendor-specific state is |
| | required) |
+------------------------------------+------------------------------+
| Peer supports MOBIKE [RFC4555] | From new exchange |
+------------------------------------+------------------------------+
| MOBIKE additional addresses | Not resumed, should be |
| | resent by client if |
| | necessary |
+------------------------------------+------------------------------+
| Time until re-authentication | From new exchange (but |
| [RFC4478] | ticket lifetime is bounded |
| | by this duration) |
+------------------------------------+------------------------------+
| Peer supports redirects | From new exchange |
| [I-D.ietf-ipsecme-ikev2-redirect] | |
+------------------------------------+------------------------------+
Also it is bit funny that there is notes 6 and 8, which are not
referenced anywhere. As those are generic rules for processing data
not covered explictly here, it might be better to make them separate
paragraph after the table, instead of hiding such important
information to the non-referenced notes.
There is also missing closing parenthesis in the end of section 3,
i.e. change
Moreover, this document requires the client to destroy the ticket
when the user explicitly "logs out" (Section 6.2.
to
Moreover, this document requires the client to destroy the ticket
when the user explicitly "logs out" (Section 6.2).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
