Re: [IPsec] Datatracker State Update Notice:

2019-12-12 Thread Tero Kivinen
Benjamin Kaduk writes: > It looks like the "reference" column for the registry dind't make it into > the -09, but I'm happy to include that change along with the last-call > feedback. If you are talking about the reference column of the IANA registries, then they are not needed in the draft (or rf

Re: [IPsec] Datatracker State Update Notice:

2019-12-12 Thread Benjamin Kaduk
On Thu, Dec 12, 2019 at 10:38:41PM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > It looks like the "reference" column for the registry dind't make it into > > the -09, but I'm happy to include that change along with the last-call > > feedback. > > If you are talking about the reference c

Re: [IPsec] Labeled IPsec options

2019-12-12 Thread Tero Kivinen
Valery Smyslov writes: > 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

Re: [IPsec] Labeled IPsec options

2019-12-12 Thread Paul Wouters
On Thu, 12 Dec 2019, Valery Smyslov wrote: 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 initi

Re: [IPsec] Labeled IPsec options

2019-12-12 Thread Paul Wouters
On Thu, 12 Dec 2019, Tero Kivinen wrote: Option 1 looks like the clearest from pure theoretical point of view, however I agree that it could lead to TS types explosion in future. Yes, I think option 1 would be most proper way of doing the negotiation. I am not sure if we are going to get that

Re: [IPsec] Labeled IPsec options

2019-12-12 Thread Paul Wouters
On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: Subject: Re: [IPsec] Labeled IPsec options +1 for option4, +0.5 for option3 One factor to consider is the granularity of label, for me it is per CHILD_SA; option1 is per TS (e.g TS with label and TS without label could be mixed in

Re: [IPsec] Datatracker State Update Notice:

2019-12-12 Thread Tero Kivinen
Benjamin Kaduk writes: > On Thu, Dec 12, 2019 at 10:38:41PM +0200, Tero Kivinen wrote: > > Benjamin Kaduk writes: > > > It looks like the "reference" column for the registry dind't make it into > > > the -09, but I'm happy to include that change along with the last-call > > > feedback. > > > > If

Re: [IPsec] Labeled IPsec options

2019-12-12 Thread Russ Housley
> On Dec 12, 2019, at 4:02 PM, Tero Kivinen wrote: > > Valery Smyslov writes: >> 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 s

Re: [IPsec] Labeled IPsec options

2019-12-12 Thread Hu, Jun (Nokia - US/Mountain View)
In line as [Hu Jun] -Original Message- From: Paul Wouters Sent: Thursday, December 12, 2019 1:25 PM To: Hu, Jun (Nokia - US/Mountain View) Cc: ipsec@ietf.org WG ; Sahana Prasad Subject: Re: [IPsec] Labeled IPsec options On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: >