Hi Michael, > > Thus, what do you want to see in the third column? "Defined in RFC > > 7296"/"Defined in this document"? > > You could say, "STD79", and "Section X" if you like.
I prefer "RFC7296", as it's better known than "STD79" :-) > >> I don't understand GSA_AUTH vs IKE_AUTH. I think that's an IKEv1-ism > >> to split it. > > > Why? When you need to substantially modify the behavior of the exchange > > you have two options - either indicate its purpose with some notify or > > introduce a new dedicated exchange. GSA_AUTH substantially differs from > > IKE_AUTH, so what's wrong with introducing a new exchange type for it? > > After all, we did it before (IKE_SESSION_RESUME, IKE_FOLLOWUP_KE). > > I guess that I'm completely unable to understand what GSA_AUTH needs to do > that's different. The similarity between IKE_AUTH and GSA_AUTH is that both complete authenticating peers and creating IKE SA. The difference is that IKE_AUTH in addition creates unicast Child SA, so the set of payloads it may/must contain corresponds to this function. GSA_AUTH creates one or more multicast Child SAs and zero or one multicast IKE SA (used for group rekeying), including direct downloading keying material from GCKS to GM. So it may/must contain very different set of payloads (apart from those used for authentication). > >> I'd consider leaving it out, or discouraging it. Obviously, one can > >> just never compress, but it seems like it's been a PITA to implement. > > > IPcomp is optional, you don't need to implement it. It can be useful if > > the traffic is compressible, especially taking into consideration that > > multicast is always udp and IP fragmentation may be an issue. On the > > other hand, if IPcomp is used for some group SA and later an GM is > > joined which doesn't support it, then a sufficiently clever GCKS could > > immediately rekey the SA with IPcomp off (taking a risk of IP > > fragmentation). > > I'm saying, it adds complexity, which means additional test cases, and > potential security holes. It seems unlikely to ever actually get used. Don't implement it if you don't need it. > > The GSA_REKEY is a pseudo-exchange, consisting of a one- way > > IKEv2 message sent by the GCKS, where the rekey policy is delivered to > > group members using IP multicast as a transport. This method is > > valuable for large and dynamic groups, and where policy may change > > frequently and a scalable rekeying method is required. > > Reasonable text, but with the clarification, I have many more questions :-) Don't hesitate to ask :-) > I think that it's conflating forwarding plane stuff with control plane stuff > in a way that is really surprising.. In G-IKEv2 both data security SAs (IPsec) and rekey SA (IKE) rely on multicast. That's the architecture choice. > >> propose some clarification text? > >> > >> It seems that GSA_RSAKEY is not an IKEv2 message at all then. > > > Why? It is a one-way IKEv2 message (but not an IKEv2 exchange!). It > > follows the format for IKEv2 messages and it is processed very much as > > usual, except that no response is sent. > > Does it travel from port 500 to port 500? > I don't think so, but maybe I just don't understand. It depends. The GCKS installs the rekey SA and informs GMs about its source and destination IP:port. I see no reasons why 500 --> 500 cannot be chosen. But actually the ports for rekey SA are arbitrary selected on GCKS discretion. > > Note, that RFC 7296 includes a concept of one-way IKEv2 messages (for > > error notification in case no IKE SA exists). > > Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY is not. GSA_REKEY is "inside" a multicast rekey SA (which is different from initial GM<->GCKS IKE SA). > > I cannot speak for others, but I'm planning to implement it. And as > > far as I know, draft 05 version of the IEEE Std 802.15.9 standard > > (March 2021) specifies that G-IKEv2 is used for group key distribution > > (but I'm not involved in this work). > > Almost nobody other that Tero has implemented 802.15.9/IKEv2. > (That's a shame, and I wish it weren't so, but sometimes you have to respect > the market choices) Market choices are volatile :-) Regards, Valery. > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
