Hi Paul,
> > I don't think option 4 is a good idea. If old responder encounters an
> > unknown payload with Critical bit set in IKE_AUTH, it will return back
> > UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up.
> > See section 2.21.2 of RFC7296. This would require initiator to retry
> > fr
On Fri, 13 Dec 2019, Valery Smyslov wrote:
I don't think that matters. Security labels are never optional but always
mandatory. And it seems very unlikely to have a mix of child sa's with and
without label. So they will all have a label, and then failing the IKE SA
is fine,
Do you want to say
On Fri, 13 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote:
If you select multiple TS's these all become part of one Child SA. So I think
the granularity of the label does not change between the solutions?
[Hu Jun] if we agree that label is per CHILD_SA, then with option 1 or 2, there
is
On Thu, 12 Dec 2019, Russ Housley wrote:
If the initiator wants to use labels but the responder does not support labels, will the
initiator move forward anyway? Doing so would seem surprising to me. The point of the
label is to indicate what handling is needed to adequately protect the data.
> >> I don't think that matters. Security labels are never optional but
> >> always mandatory. And it seems very unlikely to have a mix of child
> >> sa's with and without label. So they will all have a label, and then
> >> failing the IKE SA is fine,
> >
> > Do you want to say, that it's impossib
On Fri, 13 Dec 2019, Valery Smyslov wrote:
I don't think that matters. Security labels are never optional but
always mandatory. And it seems very unlikely to have a mix of child
sa's with and without label. So they will all have a label, and then
failing the IKE SA is fine,
Do you want to say
Hi Tero,
> > You can solve the problem of imperfect error handling by adding a new
> > SECLABES_SUPPORTED notification, that must be exchanged in
> > IKE_SA_INIT. If both peers support seclabels, then the responder must
> > not ignore seclabel notifications in IKE_AUTH and CREATE_CHILD_SA. The
> >
Reviewer: Christer Holmberg
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For mor
On Wed, 11 Dec 2019, Salz, Rich wrote:
A much better title would be
"Mixing Preshared Keys in IKEv2 for Postquantum Resistance".
That's better.
I misunderstood the document as both you and David Mcgrew kindly explained. I
withdraw my concerns and hope the title is changed.
I am fine wi
