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.
Section 2.2 recaps the payload acronyms.
I suggest a third column telling us where they are defined.
I think that GSA, KD, IDg, and SAg are new?
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.
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?
section 2.4:
GSA_REKEY The GSA_REKEY is a pseudo-exchange initiated by the GCKS,
where the rekey policy is usually delivered to group members
... no response messages are sent
so, does this violate the IKEv2 concept that all messages get acknowledged?
I guess 2.4.1 answers that question. Maybe just leave the comment to 2.4.1.
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?
"SID" is now rather overloaded in the IETF (CORE/YANG, SR6...), and perhaps
another TLA could be considered :-)
s/acieve/achieve/g in section 2.6.
s/incement/increment/
s/thus making impossible/thus making it impossible/
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.
I think that KWK should be explained in the abstract in section 1.
It seems a key architectural aspect of this document.
I got lost in section 3. I am lacking architectural understanding.
Perhaps there is some other background that I more strongly need to
understand.
I coudn't critically read Section 4, without higher level understanding.
In general, I'd rather that this was an extension to IKEv2, rather than a new
protocol. I think that IKEv1 was lacking enough orthogonality for that to
have been practical before.
I'm not sure if section 6.1 belongs here.
Who has implemented?
Or maybe I should instead ask: who cares?
--
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
