Valery Smyslov <smyslov.i...@gmail.com> wrote: > 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 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. >> 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. > 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 :-) I think that it's conflating forwarding plane stuff with control plane stuff in a way that is really surprising.. >> 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. > 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. > 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) -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec