Re: [IPsec] Labeled IPsec options

["Valery Smyslov" <[e-mail]>]

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 SA w/o proposed seclabel. In this case the initiator
> > would need to immediately delete this SA.
> 
> That is a big problem but not the only one.
> 
> > 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,
> 
> 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"

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.

> > Again, I'm fine with either using new Traffic Selectors or Notify
> > 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.

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

Regards,
Valery.

> Paul