Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-labeled-ipsec-12

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-ipsecme-labeled-ipsec-11
CC @jgscudder

Thanks for this document. I have just one comment.

## COMMENTS

I agree with Rob Wilton's point (4), about specifying things only once. The place I bumped into this was that Section 2.2 says,

  The TS_SECLABEL Traffic Selector Type MUST NOT be the only TS_TYPE
  present in the TS payload.  If a TS payload is received with only
  TS_SECLABEL Traffic Selector types, an Error Notify message
  containing TS_UNACCEPTABLE MUST be returned.

whereas Section 3 says,

  TS_SECLABEL MUST NOT be used without another TS_TYPE in a Traffic
  Selector Payload, as it does not specify a complete set of traffic
  selectors on its own.  TS_SECLABEL is complimentary to another type
  of Traffic Selector.  There MUST be an IP address Traffic Selector
  type in addtion to the TS_SECLABEL Traffic Selector type in the
  Traffic Selector Payload.

The re-specification in Section 3 seems potentially problematic in that it introduces a restriction not in the Section 2.2 text. That is, 2.2 says only that TS_SECLABEL can't appear naked, whereas 3 says that it MUST be accompanied by an IP address Traffic Selector type. Possibly this could be viewed as an irrelevant difference, but (a) might there be other selector types introduced in the future, that would sufficiently contextualize TS_SECLABEL without the presence of an IP address selector, and (b) TS_FC_ADDR_RANGE is a thing?

Please consider specifying this only once. My impulse would be to remove the quoted paragraph from Section 3 but what do I know?

### NITS

In the second quote above, s/addtion/addition/

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-ipsecme-labeled-ipsec-11
CC @jgscudder

Thanks for this document. I have just one comment.

## COMMENTS

I agree with Rob Wilton's point (4), about specifying things only once. The place I bumped into this was that Section 2.2 says,

  The TS_SECLABEL Traffic Selector Type MUST NOT be the only TS_TYPE
  present in the TS payload.  If a TS payload is received with only
  TS_SECLABEL Traffic Selector types, an Error Notify message
  containing TS_UNACCEPTABLE MUST be returned.

whereas Section 3 says,

  TS_SECLABEL MUST NOT be used without another TS_TYPE in a Traffic
  Selector Payload, as it does not specify a complete set of traffic
  selectors on its own.  TS_SECLABEL is complimentary to another type
  of Traffic Selector.  There MUST be an IP address Traffic Selector
  type in addtion to the TS_SECLABEL Traffic Selector type in the
  Traffic Selector Payload.

The re-specification in Section 3 seems potentially problematic in that it introduces a restriction not in the Section 2.2 text. That is, 2.2 says only that TS_SECLABEL can't appear naked, whereas 3 says that it MUST be accompanied by an IP address Traffic Selector type. Possibly this could be viewed as an irrelevant difference, but (a) might there be other selector types introduced in the future, that would sufficiently contextualize TS_SECLABEL without presence of an IP address selector, and (b) TS_FC_ADDR_RANGE is a thing.

Please consider specifying this only once. My impulse would be to remove the quoted paragraph from Section 3 but what do I know.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thank you for this document - I had a few minor nits and suggestions. Feel free to address, or not (they are just editorial suggestions).

1: "For example a Traffic
  Selector of TS_TYPE TS_IPV4_ADDR_RANGE for UDP traffic in the IP
  network 198.51.100.0/24 covering all ports, is denoted as (17, 0,
  198.51.100.0-198.51.100.255)"

As this is an introductory example, I think it would be helpful to explain where the numbers (17, 0) come from -- e.g "For example a Traffic
  Selector of TS_TYPE TS_IPV4_ADDR_RANGE for UDP (IP protocol 17) traffic in ..." or similar.

Huh. It turns out that I only had one nit/suggestion, so s/had a few minor nits and suggestions/a suggestion/ :-P

[Ballot comment]

# GEN AD review of draft-ietf-ipsecme-labeled-ipsec-11

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/gTc6yk7Q4jKh4sNNEQREidgJa70).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditionally`; alternatives might be `classic`, `classical`,
  `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3, paragraph 1
```
-    type in addtion to the TS_SECLABEL Traffic Selector type in the
+    type in addition to the TS_SECLABEL Traffic Selector type in the
+              +
```

#### Section 3, paragraph 2
```
-    specifed for each of those TS_TYPE, such as narrowing them following
+    specified for each of those TS_TYPE, such as narrowing them following
+          +
```

### Grammar/style

#### "Table of Contents", paragraph 1
```
curity label. A security label is comprised of a set of security attributes.
                              ^^^^^^^^^^^^^^^
```
Did you mean "comprises" or "consists of" or "is composed of"?

#### Section 3, paragraph 2
```
loads that include the TS_SECLABEL, than the Child SA MUST be created includ
                                    ^^^^
```
Did you mean "then"?

#### Section 3.1, paragraph 4
```
different specific Security Labels, than these should be negotiated in two d
                                    ^^^^
```
Did you mean "then"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]

Thank you for the work put into this document. It is easy to read and can be useful is specific use cases.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## SPD interaction

While this I-D is about IKEv2, there is little mention of interaction with IPsec SPD beside "pass the TS to the SPD". I wonder whether there must be more than a simple "pass to the SPD" operation on the responder side as the TS is opaque to IKE, so it is SPD/IPSEC that must decide whether to accept this TS, i.e., it is more than a unilateral "pass" operation.

## Section 2.2

`an Error Notify message containing TS_UNACCEPTABLE MUST be returned.` should the obvious be stated, i.e., the process stop and the proposal is not accepted ?

## No IPv6 examples in 2023 ?

Examples are always interesting and useful, but why not using IPv6 ?

[Ballot comment]
Hi,

Thanks for this document.  I found it pretty easy to read/follow and only have a few minor comments/suggestions.

Minor level comments:

(1) p 2, sec 1.  Introduction

  Traffic Selector (TS) payloads specify the selection criteria for
  packets that will be forwarded over the newly set up IPsec SA as
  enforced by the Security Policy Database (SPD, see [RFC4301]).

Should "SA" be defined, or is this wellknown?


(2) p 3, sec 1.2.  Traffic Selector clarification

  A Traffic Selector (no acronym) is one selector for traffic of a
  specific Traffic Selector Type (TS_TYPE).  For example a Traffic
  Selector of TS_TYPE TS_IPV4_ADDR_RANGE for UDP traffic in the IP
  network 198.51.100.0/24 covering all ports, is denoted as (17, 0,
  198.51.100.0-198.51.100.255)
  A Traffic Selector payload (TS) is a set of one or more Traffic
  Selectors of the same or different TS_TYPEs.  It typically contains
  one or more of the TS_TYPE of TS_IPV4_ADDR_RANGE and/or
  TS_IPV6_ADDR_RANGE.  For example, the above Traffic Selector by
  itself in a TS payload is denoted as TS((17, 0,
  198.51.100.0-198.51.100.255))

Would be better to give IPv6 examples rather than IPv4 examples (both here and below)?


(3) p 4, sec 2.2.  TS_SECLABEL properties

  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.

Why not just error (i.e., return TS_UNACCEPTABLE) , wouldn't this be the simpler thing to do?


(4) p 4, sec 3.  Traffic Selector negotiation

  TS_SECLABEL MUST NOT be used without another TS_TYPE in a Traffic
  Selector Payload, as it does not specify a complete set of traffic
  selectors on its own.  TS_SECLABEL is complimentary to another type
  of Traffic Selector.  There MUST be an IP address Traffic Selector
  type in addtion to the TS_SECLABEL Traffic Selector type in the
  Traffic Selector Payload.

I note that this text, usign RFC 2119 language, seems to be somewhat repeating the text in 1.3 and 2.2 second paragraph.  Please consider if it would be better to just state this requirement using RFC 2119 language only once.


(5) p 5, sec 3.1.  Example TS negotiation

        TSr = (((0,0,203.0.113.0-203.0.113.255),
                TS_SECLABEL1)

Looks like you might have an extra openning brace.



Nit level comments:

(6) p 6, sec 5.  IANA Considerations

  [Note to RFC Editor (please remove before publication): This value
  has already bee added via Early Allocation.

Missing closing bracket (not that it matters ...)

Thanks,
Rob

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-labeled-ipsec-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the IKEv2 Traffic Selector Types registry on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the early registration for:

Value: 10
TS Type: TS_SECLABEL

will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-04-10):

From: The IESG
To: IETF-Announce
CC: Tero Kivinen , draft-ietf-ipsecme-labeled-ipsec@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Labeled IPsec Traffic Selector support for IKEv2) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'Labeled IPsec
Traffic Selector support for IKEv2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-04-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a new Traffic Selector (TS) Type for Internet
  Key Exchange version 2 to add support for negotiating Mandatory
  Access Control (MAC) security labels as a traffic selector of the
  Security Policy Database (SPD).  Security Labels for IPsec are also
  known as "Labeled IPsec".  The new TS type is TS_SECLABEL, which
  consists of a variable length opaque field specifying the security
  label.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/



No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd: Tero Kivinen
Responsible AD: Roman Danyliw
Status: Standard Track

This document defines a new Traffic Selector (TS) Type for Internet
Key Exchange version 2 to add support for negotiating Mandatory
Access Control (MAC) security labels as a traffic selector of the
Security Policy Database (SPD).  Security Labels for IPsec are also
known as "Labeled IPsec".  The new TS type is TS_SECLABEL.

There exists an IKEv1, non-IETF, non-standard method for negotiating
Labeled IPsec for IKEv1. There was a need to standardize this for IKEv2
as to help those deploying Labeled IPsec to migrate from IKEv1 to IKEv2.

This document is adding a Traffic Selector type, and extends the core IKEv2
specification in RFC 7296 so Standard Track is suitable status for this
document when extending standard track protocol.

There has already been long experience with labeled IPsec for IKEv1,
and as this protocol simply defines similar things for IKEv2 there is
no point of having this document as experimental document.

2. Review and Consensus

The document went through a number of proposals and switched a few times
between using a Notify payload to using a Traffic Selector payload until
consensus was reached. It was also discussed whether the label should be
a variant of existing labels (e.g. IPv4_SECLABEL and IPv6_SECLABEL) and
consensus was reached on making it an independent label to avoid a
combinatorial explosion of Traffic Selector Types.

Consensus was also reached to leave the Label itself as opaque to
the IKE implementation so that it can be used with different types of
labeling systems. A small group of core developers were the the active
participants, which is quite common on the IPsecME WG. There were no
objections.

There are currently three interoperable implementations (ELVIS+,
libreswan and strongswan). ELVIS+ only implements the IKEv2 extension,
where as libreswan and strongswan use the Linux kernel SElinux system
as the labeling system. The authors have contemplated doing an
informational write up on that system in a separate new draft.

3. Intellectual Property

The authors and their employers have no IPR. The IKEv1 implementation
has no known IPR claims - it also negotiates the labels differently.
There is no known IPR regarding Labeled IPsec or its IKE negotiation.

4. Other Points

There are no downrefs. An entry is added to the IANA IKEv2 Traffic Selector
Types Registry which is Expert Review. Note that the value has already
been added as an Early Allocation and (opensource) software has already
been released that uses this value which now appears in shipped products.
Note that one interoperable implementation (ELVIS+) comes from one of the
Experts on this IANA Registry (the other Expert being one of the WG Chairs).
Both have reviewed and approved the early allocation and there is no
expectation they will now reject the IANA allocation.

1. Summary

Document Shepherd: Tero Kivinen
Responsible AD: Roman Danyliw
Status: Standard Track

This document defines a new Traffic Selector (TS) Type for Internet
Key Exchange version 2 to add support for negotiating Mandatory
Access Control (MAC) security labels as a traffic selector of the
Security Policy Database (SPD).  Security Labels for IPsec are also
known as "Labeled IPsec".  The new TS type is TS_SECLABEL.

There exists an IKEv1, non-IETF, non-standard method for negotiating
Labeled IPsec for IKEv1. There was a need to standardize this for IKEv2
as to help those deploying Labeled IPsec to migrate from IKEv1 to IKEv2.

This document is adding a Traffic Selector type, and extends the core IKEv2
specification in RFC 7296 so Standard Track is suitable status for this
document when extending standard track protocol.

There has already been long experience with labeled IPsec for IKEv1,
and as this protocol simply defines similar things for IKEv2 there is
no point of having this document as experimental document.

2. Review and Consensus

The document went through a number of proposals and switched a few times
between using a Notify payload to using a Traffic Selector payload until
consensus was reached. It was also discussed whether the label should be
a variant of existing labels (e.g. IPv4_SECLABEL and IPv6_SECLABEL) and
consensus was reached on making it an independent label to avoid a
combinatorial explosion of Traffic Selector Types.

Consensus was also reached to leave the Label itself as opaque to
the IKE implementation so that it can be used with different types of
labeling systems. A small group of core developers were the the active
participants, which is quite common on the IPsecME WG. There were no
objections.

There are currently three interoperable implementations (ELVIS+,
libreswan and strongswan). ELVIS+ only implements the IKEv2 extension,
where as libreswan and strongswan use the Linux kernel SElinux system
as the labeling system. The authors have contemplated doing an
informational write up on that system in a separate new draft.

3. Intellectual Property

The authors and their employers have no IPR. The IKEv1 implementation
has no known IPR claims - it also negotiates the labels differently.
There is no known IPR regarding Labeled IPsec or its IKE negotiation.

4. Other Points

There are no downrefs. An entry is added to the IANA IKEv2 Traffic Selector
Types Registry which is Expert Review. Note that the value has already
been added as an Early Allocation and (opensource) software has already
been released that uses this value which now appears in shipped products.
Note that one interoperable implementation (ELVIS+) comes from one of the
Experts on this IANA Registry (the other Expert being one of the WG Chairs).
Both have reviewed and approved the early allocation and there is no
expectation they will now reject the IANA allocation.

1. Summary

Document Shepherd: Tero Kivinen
Responsible AD: Roman Danyliw
Status: Standard Track

This document defines a new Traffic Selector (TS) Type for Internet
Key Exchange version 2 to add support for negotiating Mandatory
Access Control (MAC) security labels as a traffic selector of the
Security Policy Database (SPD).  Security Labels for IPsec are also
known as "Labeled IPsec".  The new TS type is TS_SECLABEL.

There exists an IKEv1, non-IETF, non-standard method for negotiating
Labeled IPsec for IKEv1. There was a need to standardize this for IKEv2
as to help those deploying Labeled IPsec to migrate from IKEv1 to IKEv2.

As it is adding a Traffic Selector type, and extends the core IKEv2
specification in RFC 7296. As there has already been long experience
with labeled IPsec for IKEv1, and this protocol simply defines similar
things for IKEv2 there is no point of having this document as experimental
document, and as it provides extension to the standard track RFC 7296, the
appropriate status for the document is Standards Track.

2. Review and Consensus

The document went through a number of proposals and switched a few times
between using a Notify payload to using a Traffic Selector payload until
consensus was reached. It was also discussed whether the label should be
a variant of existing labels (e.g. IPv4_SECLABEL and IPv6_SECLABEL) and
consensus was reached on making it an independent label to avoid a
combinatorial explosion of Traffic Selector Types.

Consensus was also reached to leave the Label itself as opaque to
the IKE implementation so that it can be used with different types of
labeling systems. A small group of core developers were the the active
participants, which is quite common on the IPsecME WG. There were no
objections.

There are currently three interoperable implementations (ELVIS+,
libreswan and strongswan). ELVIS+ only implements the IKEv2 extension,
where as libreswan and strongswan use the Linux kernel SElinux system
as the labeling system. The authors have contemplated doing an
informational write up on that system in a separate new draft.

3. Intellectual Property

The authors and their employers have no IPR. The IKEv1 implementation
has no known IPR claims - it also negotiates the labels differently.
There is no known IPR regarding Labeled IPsec or its IKE negotiation.

4. Other Points

There are no downrefs. An entry is added to the IANA IKEv2 Traffic Selector
Types Registry which is Expert Review. Note that the value has already
been added as an Early Allocation and (opensource) software has already
been released that uses this value which now appears in shipped products.
Note that one interoperable implementation (ELVIS+) comes from one of the
Experts on this IANA Registry (the other Expert being one of the WG Chairs).
Both have reviewed and approved the early allocation and there is no
expectation they will now reject the IANA allocation.

1. Summary

Document Shepherd: Tero Kivinen
Responsible AD: Roman Danyliw
Status: Standard Track

This document defines a new Traffic Selector (TS) Type for Internet
Key Exchange version 2 to add support for negotiating Mandatory
Access Control (MAC) security labels as a traffic selector of the
Security Policy Database (SPD).  Security Labels for IPsec are also
known as "Labeled IPsec".  The new TS type is TS_SECLABEL.

There exists an IKEv1, non-IETF, non-standard method for negotiating
Labeled IPsec for IKEv1. There was a need to standardize this for IKEv2
as to help those deploying Labeled IPsec to migrate from IKEv1 to IKEv2.

As it is adding a Traffic Selector type, and updates the core IKEv2
specification in RFC 7296, the document is Standards Track.

2. Review and Consensus

The document went through a number of proposals and switched a few times
between using a Notify payload to using a Traffic Selector payload until
consensus was reached. It was also discussed wether the label should be
a variant of existing labels (eg IPv4_SECLABEL and IPv6_SECLABEL) and
consensus was reached on making it an indepedent label to avoid a
combinatori explosion of Traffic Selector Types.

Consensus was also reached to leave the Label itself as opague to
the IKE implementation so that it can be used with different types of
labeling systems. A small group of core developers were the the active
participants, which is quite common on the IPsecME WG. There were no
objections.

There are currently three interoperable implementations (ELVIS+,
libreswan and strongswan). ELVIS+ only implements the IKEv2 extension,
where as libreswan and strongswan use the Linux kernel SElinux system
as the labeling system. The authors have contemplated doing an
informational write up on that system in a seperate new draft.

3. Intellectual Property

The authors and their employers have no IPR. The IKEv1 implementation
has no known IPR claims - it also negotiates the labels differently.
There is no known IPR regarding Labeled IPsec or its IKE negotiation.

4. Other Points

There are no downrefs. An entry is added to the IANA IKEv2 Traffic Selector
Types Registry which is Expert Review. Note that the value has already
been added as an Early Allocation and (opensource) software has already
been released that uses this value which now appears in shipped products.
Note that one interoperable implementation (ELVIS+) comes from one of the
Experts on this IANA Registry (the other Expert being one of the WG Chairs).
Both have reviewed and approved the early allocation and there is no
expectation they will now reject the IANA allocation.