Subject: [IPsec] Labeled IPsec options

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Dec 2019 23:58:03 -0500 (EST)

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
https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00

This option introduced a new Traffic Selector type that is similar
to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but
also contain a Security Label field

PROs:
- Early failure during IKE_AUTH when mismatched. No IPsec SA establishes
- Does not otherwise change the Traffic Selector processing
CONs:
- A bit ugly to have sort of duplicate Traffic Selector types
- All new TS types in the future would need to get a seclabel and non-seclabel version.

Option 2) TS_SECLABEL
https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02

PROs:
- No copies of TS TYPE's with/without seclabel
CONs:
- Error handling is less nice. Responder might setup an IPsec SA
   narrowed to without security label (unsupported TStypes can be
   ignored according to RFC 7296), and the initiator has to refuse
   it by sending a Delete SA message (as security labels are typically
   mandatory)
- Changes Traffic Selector processing, as now one is told that
   if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE.
   Thus updates RFC 7296 with "sub typing" of TS TYPEs.

Option 3) Use NOTIFY payloads
(not specified in a draft)

PROs:
- No changes to Traffic Selector code or specification. Easiest to
   implement.
CONs:
- Error handling is less nice. Responder might setup an IPsec SA
   without supporting the NOTIFY, and initiator has to Delete SA it.

Option 4) A new payload type like NOTIFY but now we can set Critical Flag
(not specified in a draft)
PROs:
- No changes to Traffic Selector code or specification. Easiest to
   implement.
- Can use payload with Critical Flag, so exchange fails if not
   configured or supported for security label type payload
- Error handling already done as part of standard IKEv2
CONs:
- Takes up a new payload number.
- Old Implementations might ignore Critical Flag and new payload type
   and setup IPsec SA without Security Label? New implementations not
   receiving the new payload type must also send Delete SA to prevent
   non-label IPsec SA on responder to linger.

Please let us know on the list which solution you prefer and why, so we
can make a final decision and move on :)

Paul & Sahana

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 11 Dec 2019 18:44:41 +0000

+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 the same payload), option2 is per TS payload (e.g. you could have TSi with label, TSr without label)

Option3 is a bit "abusing" the semantic of notification payload, since a "label notification" is not communicating a status, error or capability. 

-----Original Message-----
From: IPsec <[email-masked]> On Behalf Of Paul Wouters
Sent: Monday, December 9, 2019 8:58 PM
To: [email-masked] WG <[email-masked]>
Cc: Sahana Prasad <[email-masked]>
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.

This option introduced a new Traffic Selector type that is similar to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but also contain a Security Label field

PROs:

Option 2) TS_SECLABEL

PROs:

PROs:

Option 4) A new payload type like NOTIFY but now we can set Critical Flag (not specified in a draft)
PROs:

Please let us know on the list which solution you prefer and why, so we can make a final decision and move on :)

Paul & Sahana

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Dec 2019 09:11:22 +0300

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, doubling the work. Or it can create childless IKE SA
and then try CREATE_CHILD_SA - not an optimal solution too.

I also don't like option 2 since it requires changing the way TSs are handled
in IKEv2.

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.

Option 3 looks like a compromise from practical point of view.
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 drawback is that we need 
one more notification and it must be exchanged in IKE_SA_INIT,
increasing its message size. Not a big deal.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Dec 2019 23:02:08 +0200

> and then try CREATE_CHILD_SA - not an optimal solution too.

Agree fully on that. 

> I also don't like option 2 since it requires changing the way TSs
> are handled in IKEv2.

Also agree.

> 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 many new
traffic selectors in the future, so I do not think the TS types
explosion is going to be that big issue.

Also in most setups I would expect security labels to be either always
mandatory or always omitted (and that information quite often comes
directly from configuration). I do not really see that common cases
where initiator would try to use security labels and responder not
supporting them.

I.e., if you do always require security labels, there is no TS
explosion as you only propose TS with security labels. If you do not
support them, you use normal TS.

You would propose both only if you do not care whether other end
supports security labels, but are willing to use them if it supports,
but what is the meaning of security labels then? Why even propose them
if you do not care what they are?

> Option 3 looks like a compromise from practical point of view.

Agree on that too. Either option 1 or 3 would be acceptable for me,
with slight preference on option 1 because it would be proper way of
doing things. 

> increasing its message size. Not a big deal.

I am not sure we need that. I mean if initiator do require security
labels and sends security labels notification, but responder does not
reply to them, what can it do next? There isn't going to be any
communications between the peers in that case, so it should simply
tear down the SA anyways.

If it gets same information during IKE_SA_INIT (missing
SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is
not authenticated, so it will need to run IKE_AUTH to the end anyways
to make sure that there was no attack removing that
SECLABELS_SUPPORTED notification. So it will detect that error at the
end of IKE_AUTH always.

In that case there is no point of adding notification to the
IKE_SA_INIT. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Dec 2019 16:13:03 -0500 (EST)

> and then try CREATE_CHILD_SA - not an optimal solution too.

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, since no single child sa will be able to be setup
anyway. It's better than the responder setting up an SA that needs to be
torn down by the initiator sending a delete.

> in IKE_SA_INIT. If both peers support seclabels, then

But you really mean SECLABEL_REQUIRED? The "supported"
keyword here is misleading. The problem of doing this in IKE_SA_INIT
is that it could result in a spoofed answers omiting the payload?

> increasing its message size. Not a big deal.

So I'm not sure I trust this design.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Dec 2019 16:15:33 -0500 (EST)

> explosion is going to be that big issue.

That is fair.

> In that case there is no point of adding notification to the

Indeed.

PUL

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Dec 2019 16:24:41 -0500 (EST)

On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote:

> Subject: Re: [IPsec] Labeled IPsec options
> 

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?

> Option3 is a bit "abusing" the semantic of notification payload, since a "label notification" is not communicating a status, error or capability.

A bit yes :)

Paul

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Dec 2019 18:18:14 -0500

> On Dec 12, 2019, at 4:02 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Valery Smyslov writes:

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.  Moving forward without the responder agreeing to that handling seems unlikely to me.  Are there situations where moving forward is "the right thing"?

If not, then Option 1 makes the most sense to me.

Russ

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 13 Dec 2019 01:09:35 +0000

In line as [Hu Jun]

-----Original Message-----
From: Paul Wouters <[email-masked]> 
Sent: Thursday, December 12, 2019 1:25 PM
To: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; Sahana Prasad <[email-masked]>
Subject: Re: [IPsec] Labeled IPsec options

On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote:

> 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 the same payload), option2 is per TS payload (e.g. 
> you could have TSi with label, TSr without label)

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 possibility for invalid TS combination, following are some examples of invalid TS:
- with option-1: There are two TS in TSi, first TS contains label-1, 2nd TS contains label-2
- with option-2: TSi contains label-1, while TSr contains a different label-2 
With option-3/4 there is no such concern 

A bit yes :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 13 Dec 2019 17:25:14 +0300

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, doubling the work. Or it can create childless IKE SA
> 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 impossible to have two SGWs with multiple
networks behind them so, that traffic from some networks will have security
labels and traffic from the others won't have?

If such a configuration is possible, then it's perfectly OK to have a mix
of labelled and non-labelled IPsec SAs created by one IKE SA.

Regards,
Valery.

> since no single child sa will be able to be setup anyway. It's better than
the
> responder setting up an SA that needs to be torn down by the initiator
sending
> a delete.
> > 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
> 
> keyword here is misleading. The problem of doing this in IKE_SA_INIT is
that it
> could result in a spoofed answers omiting the payload?
> 
> > the responder must not ignore seclabel notifications in IKE_AUTH and
> > CREATE_CHILD_SA. The drawback is that we need one more notification
> > and it must be exchanged in IKE_SA_INIT, increasing its message size.
> > Not a big deal.
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Dec 2019 09:32:03 -0500 (EST)

> labels and traffic from the others won't have?

I'm not saying it is impossible. I am saying it is not likely to be a
real life configuration. If you classify network traffic with labels,
your goal is to not have unlabeled traffic come in at all. You might
have a label SEC_WHATEVER, but it still seems far more likely you would
mark the traffic as having come from SGWx with some kind of LABELx to
track the origin throughout your network.

> of labelled and non-labelled IPsec SAs created by one IKE SA.

I'd argue the reverse. It would likely be better not to allow such an
awful configuration :)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Dec 2019 09:51:19 -0500 (EST)

> - with option-1: There are two TS in TSi, first TS contains label-1, 2nd TS contains label-2

This issue is similar to network ranges though. Say you want to have:
10.0.1.0/24 <-> 192.168.0.0/16
10.0.2.0/24 <-> 172.16.100.0/24

Then you can also not have a TSi containing 10.0.1.0/24, 10.0.2.0/24 and
a TSr containing 192.168.0.0/16, 172.16.100.0/24

With 10.0.1.0/24+SEC_LABEL1 and 10.0.1.0/24+SEC_LABEL2 youl have a
similar issue, that is you would need to use a seperate CREATE_CHILD_SA
to prevent the mixup of TS elements.

> - with option-2: TSi contains label-1, while TSr contains a different label-2

Yes, see above.

> With option-3/4 there is no such concern

Since the notify or new payload type would be the same for all other TS
parts, you do have the same problem. You also need a different CREATE_CHILD_SA
negotiation to specify the different label. So I don't think what you
describe is a new issue only affecting some of the solution options. All
solutions need a similar workaround to prevent the mixup.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Dec 2019 09:52:41 -0500 (EST)

> 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…

I don't think anyone has come up with a real use case where the security
labels are optional.

> If not, then Option 1 makes the most sense to me.

noted.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 13 Dec 2019 17:52:49 +0300

> >> 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 impossible to have two SGWs with
> > multiple networks behind them so, that traffic from some networks will
> > have security labels and traffic from the others won't have?
> 
> I'm not saying it is impossible. I am saying it is not likely to be a real
life
> configuration. If you classify network traffic with labels, your goal is
to not
> have unlabeled traffic come in at all. You might have a label
SEC_WHATEVER,
> but it still seems far more likely you would mark the traffic as having
come
> from SGWx with some kind of LABELx to track the origin throughout your
> network.
> 
> > If such a configuration is possible, then it's perfectly OK to have a
> > mix of labelled and non-labelled IPsec SAs created by one IKE SA.
> 
awful
> configuration :)

So, am I right that you want all IPsec SAs created from a single IKE SA to
either
have labels or not? If so, then it looks like an IKE SA property, and thus
an ability
to use labels should really be negotiated when IKE SA is created
(well, I don't care whether it is SECLABELS_SUPPORTED or SECLABELS_REQUIRED 
notification :-)). And since peers know that seclabels are supported, we
won't
have any problems with legacy implementations (for example, the responder
cannot ignore label in notification in option 3).

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Dec 2019 09:59:02 -0500 (EST)

On Fri, 13 Dec 2019, Valery Smyslov wrote:

> have labels or not?

I described what I think are real life scenarios between two gateways. I
was not specifying whether did appeared in a single IKE SA or a single
IKE_AUTH/CREATE_CHILD_SA.

See my previous email how we also have IPV4 ranges that we find are not
combinable and thus we need to use a seperate CREATE_CHILD_SA to install
the subset of allowed v4 combinations. The same would apply to labels.

> If so, then it looks like an IKE SA property, and thus
> an ability

I don't think there is a need to ban the option to do it in seperate
exchanges. I don't think we need to force admins to create two IKE SA's
between the same endpoints to get labeled and unlabeled IPsec SA's.

> cannot ignore label in notification in option 3).

Sure, but one suggests the code can do it, the other suggests the
configuration insists on it. It avoids the implementor question of
"if we understand seclabels, but this connection does not use/require
them, should I answer a SECLABELS_SUPPORTED notify with a reply?".

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 13 Dec 2019 18:04:16 +0300

Hi Tero,

> > IKE_SA_INIT. If both peers support seclabels, then the responder must
> > not ignore seclabel notifications in IKE_AUTH and CREATE_CHILD_SA. The
> > drawback is that we need one more notification and it must be
> > exchanged in IKE_SA_INIT, increasing its message size. Not a big deal.
> 
> I am not sure we need that. I mean if initiator do require security labels
and
> sends security labels notification, but responder does not reply to them,
what
> can it do next? There isn't going to be any communications between the
peers
> in that case, so it should simply tear down the SA anyways.

The SA won't be created in this case, since the initiator stopped creating
it
by not initiating IKE_AUTH.

> SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is not
> authenticated, so it will need to run IKE_AUTH to the end anyways to make
> sure that there was no attack removing that SECLABELS_SUPPORTED
> notification. So it will detect that error at the end of IKE_AUTH always.

Well, the situation is no worse than with NO_PROPOSAL_CHOSEN or
with USE_PPK. In brief - if an attacker is so powerful, that it can
remove packets from the network and replace them with forged
ones, then it can break communication anyway (just drop all packets).
On the other hand, if an attacker can only inject packets, then 
the responder's packet will eventually reach the initiator.

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 a message with SECLABELS_SUPPORTED, then go with it.

Regards,
Valery.

> In that case there is no point of adding notification to the IKE_SA_INIT.
> --
> [email-masked]
>

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 16 Dec 2019 19:05:26 +0000

-----Original Message-----
From: Paul Wouters <[email-masked]> 
Sent: Friday, December 13, 2019 6:51 AM
To: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; Sahana Prasad <[email-masked]>
Subject: RE: [IPsec] Labeled IPsec options

Then you can also not have a TSi containing 10.0.1.0/24, 10.0.2.0/24 and a TSr containing 192.168.0.0/16, 172.16.100.0/24

With 10.0.1.0/24+SEC_LABEL1 and 10.0.1.0/24+SEC_LABEL2 youl have a similar issue, that is you would need to use a seperate CREATE_CHILD_SA to prevent the mixup of TS elements.
[Hu Jun] since this label is new, ideally we should avoid to have such similar issue; and if this the label is per CHILD_SA, then of course it will require multiple CHILD_SA to have multiple labels, I don't think that's an issue. So again, I think WG need to get a consensus on the granularity of label before an option could be decided , is it per tunnel, per CHILD_SA or per TS?  for me it is per CHILD_SA

Yes, see above.

> With option-3/4 there is no such concern

Since the notify or new payload type would be the same for all other TS parts, you do have the same problem.
[Hu Jun] sorry, but I fail to see why option-3/4 have same problem if the label is per CHILD_SA and semantic of new notification/payload is for the whole CHILD_SA 
 You also need a different CREATE_CHILD_SA negotiation to specify the different label. So I don't think what you describe is a new issue only affecting some of the solution options. All solutions need a similar workaround to prevent the mixup.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Dec 2019 23:37:57 +0200

> If it receives a message with SECLABELS_SUPPORTED, then go with it.

Which means configuration errors result in timeout instead of getting
clear error message that there is configuration error.

I.e., when initiator changes configuration and add
SECLABELS_SUPPORTED, and then tries to connect SGW, instead of getting
error message saying SECLABLES were not supported by other end it will
result in unauthenticated error messages and then finally timeout.

I always prefer to get proper authenticated error message from the
other end for configuration errors. I.e., if we instead propose
traffic selectors with SECLABELS and we should get TS_ACCEPTABLE error
message from the responder and that clearly indicates that there is
configuration error.

>From the RFC7296 section 2.9:

----------------------------------------------------------------------
...
   If the type of Traffic Selector proposed is unknown, the responder
   ignores that Traffic Selector, so that the unknown type is not
   returned in the narrowed set.
...
The responder performs the narrowing as follows:

   o  If the responder's policy does not allow it to accept any part of
      the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
      Notify message.
...
----------------------------------------------------------------------

I.e., if the other end does not support TS type containing labels, it
will ignore them and not include them in the narrowed set. If the
narrowed set becomes empty because of that it will return
TS_UNACCEPTABLE error message to the initiator and that gives clear
feedback that there is configuration error.

This is much more preferred than waiting for some time and then after
timeout decide that there might have been configuration error...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 25 Dec 2019 17:34:56 +0300

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 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 SA w/o proposed seclabel. In this case the initiator 
would need to immediately delete this SA.

My proposal only deals with this situation. If initiator and responder
exchange SECLABELS_SUPPORTED notifications at the time of 
creating IKE SA (in IKE_SA_INIT), then the initiator will know,
whether the responder supports seclabels or not. And if the 
responder supports seclabels, it will not be able to ignore notification 
(of other type) indicating the desired security label at the time 
Child SA is created (in IKE_AUTH or in CREATE_CHILD_SA).

So you misunderstood, there is no any timeouts, there is 
clear indication for the initiator of whether the responder supports 
this feature (and thus it's OK to use it) or not (in which case
depending on the initiator's policy the communication
may or may not be possible).

Again, I'm fine with either using new Traffic Selectors or Notify 
for this purpose. Both have pros and contras. 

Regards,
Valery.

> ....
> ....
> ....

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Dec 2019 13:01:58 -0500 (EST)

> would need to immediately delete this SA.

That is a big problem but not the only one.

> creating IKE SA (in IKE_SA_INIT), then the initiator will know,

During IKE_SA_INIT you do not fully know which configuration you are
talking to, as no ID's have been exchanged. If a server has some
connections with and some without security labels, it cannot guarantee
success despite the notification. And that is assuming the notification
does not indicate "support" but indicates "supported and required"

> for this purpose. Both have pros and contras.

I think the majority seems to be in favour of Traffic Selectors. While
a combinatory explosion is a worry, we do not expect that many new types
of traffic selectors, so it is unlikely to become a big problem I think.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 27 Dec 2019 10:06:26 +0300

Hi Paul,

> does not indicate "support" but indicates "supported and required"

The successful exchange of SECLABELS_SUPPORTED notification only
ensures that the responder won't ignore SECLABEL notification
in requests to create IPsec SAs. In this case, if for any reason
the server cannot create IPsec Sa with proposed security label
(that is provided in SECLABEL notification), the server would 
return TS_UNACCEPTABLE (or NO_PROPOSAL_CHOSEN).

So, SECLABELS_SUPPORTED doesn't say that every 
IPsec SA created with this IKE SA will have security labels,
it only guarantees that notifications containing security
labels won't be silently ignored.

> of traffic selectors, so it is unlikely to become a big problem I think.

OK, I think it's a right way to go. In fact I suggested it back in May 2018 :-)

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Dec 2019 15:25:48 -0500 (EST)

On Fri, 27 Dec 2019, Valery Smyslov wrote:

> in requests to create IPsec SAs.

Over the hollidays, I tried to show weaknesses in this approach,
but failed. I think Valery is right. Although, I'm not sure yet
what an initiator requiring labels would do if the responder
replied without the notify. Should it delete/retry the exchange,
or start an IKE_AUTH with some kind of (new?) notify error ?
Or should it go ahead regardless as to not leak to the network
that this IPsec SA uses labels, and wait for the remote end to
return an inevitable TS_UNACCEPTABLE?

On the responder, I'll assume that it will continue in general
with the IKE_SA_INIT reply even if it is missing the notify and
it has some connections configured to use labels. Since it does
not know for sure in all situation if its IKE_SA_INIT reply
generated is for the proper connection (if it has multiple connections
configured). So here too, after the responder receives Traffic Selectors
of the non-label kind, it will return TS_UNACCEPTABLE.

> OK, I think it's a right way to go. In fact I suggested it back in May 2018 :-)

I paid in time for my reluctance to be convinced by you and Tero at that time :)

Paul