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

[Michael Richardson <[e-mail]>]

Valery Smyslov <[e-mail]> wrote:
    > many thanks for your review. Much appreciated.

    > Please, see inline.

    >> I started reading through this document during IETF115, but didn't
    >> finish until today.  I don't think that I have ever read the IKEv1-G
    >> stuff.
    >>
    >> > G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407], because
    >> > they serve a similar function.  They can use the same ports, just as
    >> > IKEv1 and IKEv2 can share port 500.  The version number in the IKE >
    >> header distinguishes the G-IKEv2 protocol from GDOI protocol >
    >> [RFC6407].  G-IKEv2 MAY also use the IKEv2 ports (500, 4500), which >
    >> would provide a better integration with IKEv2.  G-IKEv2 MAY also use >
    >> TCP transport for registration (unicast) IKE SA, as defined in >
    >> [RFC8229].
    >>
    >> Based upon this text, I would have no idea when/if I can send my
    >> G-IKEv2 packet to port 500 or 848.

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

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

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

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

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

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

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

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

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

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

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