Hi Tero,
> > > Do you think the current diagrams are confusing?
> >
> > Yes. Because often I go back to RFCs and only look at the diagrams
> > expecting it to be what I need to implement. So for optional/required
> > payloads, I would mostly look at the diagram, and perhaps read a bit
> > of text.
>
> That is the reason we added Appendix C in the IKEv2.
>
> So my proposal is to leave the exchanges inside the text as they are,
> but add new Appendix that has the different exchanges including the
> optional payloads.
I don't think it's justified for such small changes in IKE exchanges
(a couple new notifications). Instead, I suggest to add the following
short clarification after the picture:
Initiator Responder
----------------------------------------------------------------
HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP}
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH,
N(PPK_IDENTITY, PPK_ID)
[, N(NO_PPK_AUTH)]} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr
[, N(PPK_IDENTITY)]}
Note, that the diagram above shows both the cases when the responder
uses PPK and when it chooses not to do it (provided the initiator has
included NO_PPK_AUTH notification), so the responder's PPK_IDENTITY
notification is marked as optional.
Is it OK? Paul?
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
