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
