Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

[Michael Richardson <[e-mail]>]

Valery Smyslov <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide