Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08

[Paul Wouters <[e-mail]>]

On Tue, 5 Nov 2019, Benjamin Kaduk wrote:

> Oh, this is probably the key part of my confusion/misunderstanding with the
> terminology (which also shows up later on, IIRC).
> Namely, that the initial exchange generates an IKE SA, and the other SAs
> ("children" for ESP/AH usage) are called IPsec SAs (not IKE SAs).
> In that case this text is fine as-is and there's nothing to change, so
> sorry for the noise.

Sorry, I do want to clarify this to be sure you got it completely right:

In IKEv1, you first setup an IKE SA (then called ISAKMP SA) using eiher
the Main or Aggress Mode Exchange, and then you do one or more Quick Mode
Exchanges to setup the first and subsequent IPsec SA's.

In IKEv2, the Initial Exchanges (1 IKE_SA_INIT plus 1 IKE_AUTH exchange)
create one IKE SA (now called Parent SA) nd one IPsec SA (now also called
Child SA) at the same time. Additional IPsec SA's can be created using
the CREATE_CHILD_SA exchange.

In IKEv2, we don't talk about ISAKMP SA anymore. I think people hoped
that in IKEv2 we would not talk about IKE SA and IPsec SA anymore (but
only talk about Parent SA and Child SA) but I don't think in reality
that is happening. I know our developers continue to disagree about what
to call certain things in code and documentation :)

This all does make it a little confusing. I can recommend the new NIST
Guide to IPsec VPNs SP800-77r1 document where I explain all these terms
as well :)

>>>                                    <--  HDR, SK {AUTH, SAr2, TSi, TSr
>>>                                         [, N(PPK_IDENTITY)]}
>>>
>>> Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as
>>> optional here in the EAP case but not in the previous diagram for the
>>> non-EAP case?
>>
>> In the previous diagram we consider only the case when using
>> PPK is agreed upon, so N(PPK_IDENTITY) is not optional.

This btw, is a little weird. I think it is better to have the "generic"
exchange documented, and in the text write specific examples of when
payloads are or aren't t there. I think the figures/diagrams should be
drawn to represent the generic case, where it should be optional because
if it does not know the right PPK_ID, it will not send the notify.

That is, the diagrams should represent the state machine, not an
example of the state machine.

Paul