On Fri, 27 Dec 2019, Valery Smyslov wrote:
The successful exchange of SECLABELS_SUPPORTED notification only
ensures that the responder won't ignore SECLABEL notification
in requests to create IPsec SAs.
Over the hollidays, I tried to show weaknesses in this approach,
but failed. I think
Hi Paul,
> > Another approach - use some new status notification containing
> > seclabel that the initiator would include in any request to create
> > Child SA. This is easy to implement, but there is a possibility,
> > that unsupporting responder will just ignore this notification
> > and create
On Wed, 25 Dec 2019, Valery Smyslov wrote:
Another approach - use some new status notification containing
seclabel that the initiator would include in any request to create
Child SA. This is easy to implement, but there is a possibility,
that unsupporting responder will just ignore this
Hi Tero,
first, I'm not against using new TS accommodating seclabels.
It is the most pure way to go from theoretical PoV.
The only concern with this approach is that the number of TS types will
be growing up.
Another approach - use some new status notification containing
seclabel that the
Valery Smyslov writes:
> In our case the strategy for initiator is: retransmit and wait.
> If even after several retransmission it doesn't receive message
> with SECLABELS_SUPPORTED, then there is no reason to continue
> with IKE_AUTH (if using labels is mandatory for initiator).
> If it receives
-Original Message-
From: Paul Wouters
Sent: Friday, December 13, 2019 6:51 AM
To: Hu, Jun (Nokia - US/Mountain View)
Cc: ipsec@ietf.org WG ; Sahana Prasad
Subject: RE: [IPsec] Labeled IPsec options
On Fri, 13 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote:
>> If you
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
>
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
> >> 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
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
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 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
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
> >
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
> 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
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
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
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
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
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 from
IKE_SA_INIT,
hana Prasad
Subject: [IPsec] Labeled IPsec options
Hi,
As agreed at IETF 106, we would write up the options for negotiating Labeled
IPsec that we have discussed, with their PROs and CONs, so that the working
group can make a final decision.
Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6
Hi,
As agreed at IETF 106, we would write up the options for negotiating
Labeled IPsec that we have discussed, with their PROs and CONs, so
that the working group can make a final decision.
Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL
22 matches
Mail list logo
