Re: [IPsec] [saag] IETF 114 IPsecME report

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> On Fri, Sep 23, 2022 at 1:15 PM Paul Wouters <[e-mail]> wrote:
> 
>     On Mon, Jul 25, 2022 at 10:24 PM Tero Kivinen <[e-mail]> wrote:
> 
>          Labeled IPsec is ready for publication and
>         will be submitted to the IESG immediately after this IETF.
> 
>     This has still not happened. The Shepherd's write up looks done, so it
>     would be nice if you can push this to Roman.
> 
> I said that 4 months ago :(
> 
> Tero, please grab a coke zero and spend an hour to push this forward. Let's
> not wait yet another IETF please.

Sorry no coke zeros here, I only drink Pepsi-max at home :-)

Anyways checking the document now, and first of question I have why it
is standard track not experimental.

The shepherd writeup says:

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

but even if it adds new traffic selector type, I do not really see any
reason for it to be standard track it could be experimental.

Also I am not sure it even updates RFC7296. It adds new traffic
selector type, and adds new rules how that must be narrowed, but it
does not affect any old implementations. Old implementations do not
need to be changed because of this draft if they do not want to
support this.

Actually now when I am reading it I can see it provides all kind of
incorrect updates to the RFC7296, that will BREAK old implementations.

For example the 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.

and section 1.3

   The negotiation of Traffic Selectors is specified in Section 2.9 of
   [RFC7296] and states that the TSi/TSr payloads MUST contain at least
   one Traffic Selector type. This document updates the text to mean
   that the TSi/TSr payloads MUST contain at least one Traffic Selector
   of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE, as other Traffic
   Selector types can be defined that are complimentary to these Traffic
   Selector Types and cannot be selected on their own without
   TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.

are wrong. 

The RFC 7296 says:

   Each TS payload contains one or more Traffic Selectors. Each
   Traffic Selector consists of an address range (IPv4 or IPv6), a
   port range, and an IP protocol ID.

There is no mandatory text there, this is all just explaining what
traffic selectors are. Implicitly there will be one traffic selector
as the selectors are taken from the policy, and if we matched some
policy then there must be something that we will fill in the Traffic
Selectors, but even that is not required by RFC7296.

The requirement that each "TSi/TSr payloads MUST contain at least one
Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE" is
incorrect, and cannot be added to RFC7296 directly or in here.

There is for example TS_FC_ADDR_RANGE, and it is completely valid to
only include TS_FC_ADDR_RANGE types and no TS_IPV4_ADDR_RANGE or
TS_IPV6_ADDR_RANGE selectors. The RFC4595 defines this
TS_FC_ADDR_RANGE and it contains 24-bit addresses for Fibre Channel
communications, and other fields which I assume can be narrowed using
regular rules specified in the RFC7296 (as RFC4594 does not specify
its own narrowing rules).

Only the TS_SECLABEL selector defined in this document is
"complimentary to these Traffic Selector Types and cannot be selected
on their own without TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE."

There can be other traffic selectors defined in the future which do
not require TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE types at all,
thus that kind of limitation cannot be done here.

For example the IEEE Std 802.15.9 negotiating keys for the IEEE Std
802.15.4 does not use TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE at
all, as there is no IP-addresses there. Currently it does not define
its own TS_TYPEs, it simply says we use Childless Initiation of IKEv2,
thus there will not be TS payloads, and it will derive pairwise key
between the two devices using SK_d and nonces. In the future there
might be need to actually specify addresses also, and then they would
need to come in IETF and specify new TS_TYPE to be used there.

This document should simply say that TS_SECLABEL MUST NOT be used
alone. This document must not try to do incompatible change to the
base RFC7296 which would make conforming implemntations
non-conforming.

So I do not think this document should update RFC7296 at all, so most
of the section 3 is wrong.

The first bullet in section 3 is wrong, and second is already allowed
by RFC7296, there nothing that says there cannot be one more more
other TS_TYPES, thus it is not needed.

Section 3 should most likely say something like this:

   The TS_SECLABEL cannot be used alone as it does not specify traffic
   selectors completly, it is just complimentary to other traffic
   selectors. Because of this there MUST be some other TS_TYPEs in
   addition to TS_SECLABEL in the Traffic Selector Payload when it is
   used in negotiation. 

   If the TSi Payload contains a traffic selector for TS_TYPE of
   TS_SECLABEL, a responder MUST create each TS response for other
   TS_TYPEs than TS_SECLABEL, using normal rules specifed for each
   TS_TYPE (narrowing them following the rules specified for that
   TS_TYPE), and then add exactly one for the TS_TYPE of TS_SECLABEL.
   If this is not possible, it MUST return a TS_UNACCEPTABLE Error
   Notify payload.

   If a TS_SECLABLE is deemed optional, the initiator SHOULD first try
   to negotiate the Child SA with the TS payload including the
   optional TS_SECLABEL. Upon receiving TS_UNACCEPTABLE, it SHOULD
   attempt a new Child SA negotiation using the same TS but without
   the optional TS_SECLABEL.
-- 
[e-mail]