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

[Valery Smyslov <[e-mail]>]

Hi Michael,

>     > I think it must be pre-configured (just as, for example, using TCP
>     > encapsulation in IKEv2).  Should we add some text?
> 
> If it's an arbitrary port that someone has to configure, then please include
> no ports.
>
> I don't think it should be that way.
> 
> I think that it should be port 500.
> I don't know if the option to also listen on port 848 matters.
> That reflects my preference that this work be an IKEv2 extension,
> rather than a new protocol like the IKEv1 version.

I think the text can be changed to indicate that using IKE ports is RECOMMENDED
and udp/848 is MAY (to allow compatibility with GDOI).

>     >> 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?
> 
> No, I'd rather see it all in one table.

Thus, what do you want to see in the third column? 
"Defined in RFC 7296"/"Defined in this document"?

>     >> 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.
> 
> 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).

>     >> 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).
> 
> 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 guess 2.4.1 answers that question.  Maybe just leave the comment to
>     >> 2.4.1.
> 
> > Can you suggest some wording?
> 
> remove: "This is not a real IKEv2 exchange, since no response messages are sent."

OK. I also added some clarification to this para:

         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.  When the GSA_REKEY is used, the IKE SA protecting
         the member registration exchanges is usually terminated, and
         group members await policy changes from the GCKS via the
         GSA_REKEY messages.

Is it better?

>     >> 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?
> 
> 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.

Note, that RFC 7296 includes a concept of one-way IKEv2 messages
(for error notification in case no IKE SA exists).

>     >> "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?
> 
> SenderID is way better.
> (CORE/YANG has Schema ID, SR6 has SegmentID)

OK.

>     >> 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.
> 
> Is the KWK part of IKEv2 or is it part of ESP?

It is part of IKEv2 (precisely - G-IKEv2). 

>     >> 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).
> 
> It seems like it belongs in smyslov-ipsecme-ikev2-qr-alt.
> I don't feel strongly.

I disagree. This section mostly discusses the cumbersomeness of 
getting the QC protection for multicast keys by using RFC 8784. 
smyslov-ipsecme-ikev2-qr-alt is only mentioned as more suitable alternative.

>     >> 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 :-)
> 
> We shouldn't waste resources publishing documents that nobody plans to deploy.
> (We have enough to do...)

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).

Regards,
Valery.

> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>