For most other features (e.g. whether peer supports MOBIKE or not), the draft already says that the relevant payloads (e.g. MOBIKE_SUPPORTED) are sent in the new exchange (instead of assuming everything has remained the same).
IMHO the simplest alternative would be to use the same approach for Vendor IDs, too. This is needed even when no vendor-specific data is stored in the ticket, because vendor IDs define how to interpret numbers from the "private use" range... Best regards, Pasi > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of ext Tero Kivinen > Sent: 17 August, 2009 14:34 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2- > resumption > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
