Valery Smyslov <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
