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

[Valery Smyslov <[e-mail]>]

>     >> > 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 prefer "RFC7296", as it's better known than "STD79" :-)
> 
> Yet, it's incorrect.

I'm not sure.

> It fails to include the updates, and it goes stale.

The table of payloads in the G-IKEv2 spec will not contain updates anyway.
It lists the payloads defined in RFC 7296 and thus it seems 
appropriate to reference a document where they are defined, 
not its future updates. As, for example, IANA registries do.

> It also wastes all the effort we put into bringing it to Internet Standard.

Bad or good, I believe it is a common practice in IETF, no?
For example, a well-known RFC 822 is also STD 11, but it is rarely referenced by the latter name...

>     > The similarity between IKE_AUTH and GSA_AUTH is that both complete
>     > authenticating peers and creating IKE SA. The difference is that
>     > IKE_AUTH in addition creates unicast Child SA, so the set of payloads
> 
> It does?

I'm puzzled. Do you have any doubts?

Quoting RFC 7296 Section 1 (Introduction):

   In the common
   case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH
   exchange (a total of four messages) to establish the IKE SA and the
   first Child SA.

Am I missing the point?

>     >> > 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.
> 
>     > GSA_REKEY is "inside" a multicast rekey SA (which is different from
>     > initial GM<->GCKS IKE SA).
> 
> I think that this new SA needs to be introduced.

It is introduced. Section 1:

   Group rekeys are accomplished
   using ... the GSA_REKEY pseudo-exchange (a single message
   distributed to all GMs, usually as a multicast message) ...

> I think that there need to be some diagrams.

Figure 1 shows the case where rekeying is being done over multicast.

Do you think more clarifications are needed?

Regards,
Valery.

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