On Wed, 20 Jan 2021, Valery Smyslov wrote:
First, it's not clear for me why zero length TS_SECLABLE is prohibited.
The draft currently says
A zero length Security Label MUST NOT be used. If a received TS
payload contains a TS_TYPE of TS_SECLABEL with a zero length Security
Label, that specific Traffic Selector MUST be ignored.
I wonder what's rational behind this restriction. From my point of view
zero length TS_SECLABLE can be used to express that using Security Labels
is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector
along with other TS_SECLABEL Traffic Selectors to indicate that responder
is free to not use security labels for the SA.
We did discuss this earier in the WG. There is no use case of "optional"
security labels. You either insist on these, or you don't use these.
Implementing "optional" ones by using a zero length label is asking for
implementation problems. Especially when people consider these labels
as strings and run strlen() on the empty (but NULL terminated string)
and interpret that as wildcard.
Since there is no use case, and significant implementation danger, the
document makes an explicit case to reject these. Our implementation
will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL.
Currently draft suggests
the initiator to perform several attempts to establish IPsec SA
with and without TS_SECLABEL Traffic Selectors in such situation,
which is more complicated and less efficient. Am I missing something?
It was what the WG preferred to do. The reasoning was that labels are
surely very much preconfigured and connections will not be migrated
from "no security" to "security label" where the operator wants to
operate insecurely first. That is, opportunistic security labels is
not a thing.
The case you describe is very unlikely. Either the endpoints wants a
label or doesn't want one. optional security is not security.
Another my concern is that draft allows security labels to differ
in TSi and TSr without giving any possible semantic interpretation for this.
Correct. But the label is clearly defines as opaque to the IKE layer.
The IKE layer should not be making any kindds of assumptions or
interpretations, but just relay this to the underlying label security
consumer (eg in our case the LSM of SElinux). Note that our
implementation only supports symmetrical labels so far, because
that is how SElinux labeling works. But the protocol can accept
other methods.
This looks weird. I think that at least some possible interpretation
of such situation must be given, e.g. TS_SECLABEL in TSi is used
for traffic from initiator to responder and TS_SECLABEL in TSr
is used for the return traffic. In this case it is clear that
they can differ in some situations.
I'm not sure why this is not clear? TSi and TSr entries apply to
one direction. TS_SECLABEL does not change that.
And the last (but not the least). It seems to me that Section 3
(which aims to update Section 2.9 of RFC 7296) oversimplifies
the negotiation process.
Again, we followed the consensus of the group here.
In particular, the sentence
A responder MUST create its TS response by selecting one of each
TS_TYPE present in the offered TS by the initiator.
is inaccurate in my opinion, since it implies (as I read it) that responder can
pick
exactly one traffic selector of each TS_TYPE and can only return it unmodified.
How about this clarification:
A responder MUST create its TS response by selecting at least
one of each TS Type. One exception is that a responder MAY omit
a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least
one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected.
Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE
content
set MAY be selected.
Note that this is mentioned already in section 1.2:
A Traffic Selector payload (TS) is a set of one or more Traffic
Selectors of the same or different TS_TYPEs, but MUST include at
least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.
If you prefer other text, please provide your suggestion.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
