Hi Michael, many thanks for your review. Much appreciated.
Please, see inline. > I started reading through this document during IETF115, but didn't finish > until today. I don't think that I have ever read the IKEv1-G stuff. > > > G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407], because > > they serve a similar function. They can use the same ports, just as > > IKEv1 and IKEv2 can share port 500. The version number in the IKE > > header distinguishes the G-IKEv2 protocol from GDOI protocol > > [RFC6407]. G-IKEv2 MAY also use the IKEv2 ports (500, 4500), which > > would provide a better integration with IKEv2. G-IKEv2 MAY also use > > TCP transport for registration (unicast) IKE SA, as defined in > > [RFC8229]. > > Based upon this text, I would have no idea when/if I can send my G-IKEv2 > packet to port 500 or 848. I think it must be pre-configured (just as, for example, using TCP encapsulation in IKEv2). Should we add some text? > Section 2.2 recaps the payload acronyms. > I suggest a third column telling us where they are defined. Perhaps it's better to split the table into to - existing IKEv2 payloads and newly defined G-IKEv2-specific payloads. Does it work for you? > I think that GSA, KD, IDg, and SAg are new? Yes. > Can I do unicast IKE_CHILD_SA echanges in the same PARENT_SA as I do G-IKEv2? > I can imagine use cases where there is both multicast and unicast traffic > that needs to be protected. > I guess not, beacuse GSA_AUTH is not IKE_AUTH. You cannot create unicast IPsec SA at the time the G-IKEv2 SA is being established (since GSA_AUTH cannot do it). It's an open question whether you can create them once it is up (via CREATE_CHILD_SA). It is not explicitly prohibited now, but would prefer not to do it - use G-IKEv2 SA for group key management traffic only and create a separate IKEv2 SA if the GCKS acts as a GW too. > Use of IPCOMP seems really difficult. I guess it can't be used until every > receiver supports it. Is that common? Are the target use cases (probably > video?) even compressible? With multicast architecture for any single feature used, every receiver have to support it, IPcomp is not an exception. Using IPcomp is defined for completeness. No target use cases were considered (I think there may be few of them). > section 2.4: > GSA_REKEY The GSA_REKEY is a pseudo-exchange initiated by the GCKS, > where the rekey policy is usually delivered to group members > ... no response messages are sent > > so, does this violate the IKEv2 concept that all messages get acknowledged? Yes :-) That's why it is called "pseudo-exchange". > I guess 2.4.1 answers that question. Maybe just leave the comment to 2.4.1. Can you suggest some wording? > Are these IKEv2 messages sent in the normal port 500/848/4500 channel? Or? > I don't understand this part at all. There are implications that it's > multicast, but clearly, it can't be? GSA_REKEY is sent over multicast (that's why it is unacknowledged). The port it is sent to is specified by the GCKS in the GSA_AUTH exchange (it can be any UDP port). Can you be more specific of the text that is not clear and perhaps propose some clarification text? > "SID" is now rather overloaded in the IETF (CORE/YANG, SR6...), and perhaps > another TLA could be considered :-) This term was used in the draft from its early versions :-) Perhaps change to SenderID? Or SENDER_ID? Or is it overloaded too? > s/acieve/achieve/g in section 2.6. > s/incement/increment/ > s/thus making impossible/thus making it impossible/ Thank you, will fix. > I think that the end of section 2.6, aout reusing Extended Sequence Number > should probably have more widespread review within the WG. > This is not just a key mgmt issue, but an 4301 update I think. Actually, the current text in the draft is misleading. It is not about reusing, the transform meaning is generalized and a new value for transform ID is added. We'll try to make the text more clear. I'm not sure it is an update to 4301, since it requires no code change for existing implementations. > I think that KWK should be explained in the abstract in section 1. OK. > It seems a key architectural aspect of this document. > I got lost in section 3. I am lacking architectural understanding. > Perhaps there is some other background that I more strongly need to > understand. Section 1 gives some high-level view of the architecture. Do you think it should be expanded or more details be added to the Section 3? Probably add a sub-section? > I coudn't critically read Section 4, without higher level understanding. > > In general, I'd rather that this was an extension to IKEv2, rather than a new > protocol. I think that IKEv1 was lacking enough orthogonality for that to > have been practical before. It was started as a new protocol, but now it is more like an IKEv2 extension. > I'm not sure if section 6.1 belongs here. Why? It describes how PPK can be used (well, how complicated is to use it :-)) with G-IKEv2 and also has some justification for alternative way of using PPK (defined in drft-smyslov-ipsecme-ikev2-qr-alt). > Who has implemented? As far as I know early versions of the draft (incompatible with the current one) were implemented by Cisco and by Tobias Heider and Tobias Guggemos. The current version is partially implemented by myself. > Or maybe I should instead ask: who cares? I believe that there is some interest in this work. I cannot estimate how strong it is :-) Regards, Valery. > > > > > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
