Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick <[e-mail]>]

Hi Benjamin

As I was preparing the next revision of this document, I realised I'd forgotten to reply to your email.  (I thought I had replied, but I can find no evidence that I did so!)

Anyway, I think we have converged.  Please see my proposals below, and apologies for my tardiness.

Cheers
Jon

----
> Isn't the 'F' bit fully redundant with NT?
> 
> [Jon] The F bit determines whether NAI is appended, or not.  NT gives the type of the NAI that is appended.  The NT field has no meaning if F=0.

My (implicit) proposal was to assign a value for the NT field that means "no NAI is present", and to treat that value of NT as meaning that F=0, with any other value of NT meaning F=1, in which case the F bit does not add any new information.

[Jon2] Understood. Unfortunately, we have to make a pragmatic decision here as implementations are already fielded.  I have changed the text to say this to clarify.

NEW
   NAI Type (NT):  Indicates the type and format of the NAI contained in
      the object body, if any is present.  If the F bit is set to zero
      (see below) then the NT field has no meaning and MUST be ignored
      by the receiver.
END NEW

----
> It's interesting that the routing protocols' MSD value supersedes the PCE-obtained one, given that all three (IS-IS, OSPF, and BGP-LS) documents have text to the effect of "PCEP provides a way to get this, but if PCEP is not used you can use our thing", which a naive reader would take to mean that PCEP is intended to be the primary distribution mechanism.
> 
> [Jon] Probably needs to be fixed in the other documents.  PCEP is a fairly blunt tool for specifying the MSD, which it can only do per node.  The IGPs can do better by specifying the MSD per network interface.

Ah.  Unfortunately, at least the IS-IS document is already published as an RFC (8491) and thus immutable.  (I didn't check the others.)  I don't know whether it would be appropriate to add this explanation into this document since the other documents cannot (all) be changed.

[Jon2] I've reworded the text to make the relationship between PCEP and the IGPs clearer:

NEW
   Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV
   indicates the SID/label imposition limit for the PCC node.  It is
   anticipated that, in many deployments, the PCCs will have network
   interfaces that are homogeneous with respect to MSD (that is, each
   interface has the same MSD).  In such cases, having a per-node MSD on
   the PCEP session is sufficient; the PCE SHOULD interpret this to mean
   that all network interfaces on the PCC have the given MSD.  However,
   the PCE MAY also learn a per-node MSD and a per-interface MSD from
   the routing protocols, as specified in: [RFC8491]; [RFC8476];
   [I-D.ietf-idr-bgp-ls-segment-routing-msd].  If the PCE learns the
   per-node MSD of a PCC from a routing protocol, then it MUST ignore
   the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the
   per-node MSD learned from the routing protocol instead.  If the PCE
   learns the MSD of a network interface on a PCC from a routing
   protocol, then it MUST use the per-interface MSD instead of the MSD
   value in the SR-PCE-CAPABILITY sub-TLV when it computes a path that
   uses that interface.
END NEW


----
> I don't think it's a good idea to just refer to "the security 
> mechanisms of [RFC 5440] and [RFC8281]", since there are qualitative 
> differences between the TCP authentication schemes and the full-on 
> encryption provided by TLS and IPsec.  (Also, what exactly are the 
> security mechanisms of RFC8281 supposed to be -- a quick look only 
> sees the new guidance to apply resource
> limits?)  The second paragraph only requires integrity protection to avoid the vulnerability mentioned there, but the third paragraph requires confidentiality protection to preent the attack.
> 
> [Jon] RFC 8281 pulls in RFC 8231 in its security section, as you note 
> above.  RFC 8231 says
> 
>    As a general precaution, it is RECOMMENDED that these PCEP extensions
>    only be activated on authenticated and encrypted sessions across PCEs
>    and PCCs belonging to the same administrative authority, using
>    Transport Layer Security (TLS) [PCEPS], as per the recommendations
>    and best current practices in [RFC7525].

That still doesn't seem to give the reader much guidance about which cases require encryption and which cases can safely proceed with just integrity protection (even though I'm happy to see the general recommendation to use TLS!).

[Jon2] OK, I understand. The strong steer is that TLS should be used all the time, but we haven't mandated it, so you are right, more guidance should be given.  I think your analysis is correct, so I've changed the text in the second and third paragraphs as follows.

NEW
   Note that this specification enables a network controller to
   instantiate a path in the network without the use of a hop-by-hop
   signaling protocol (such as RSVP-TE).  This creates an additional
   vulnerability if the security mechanisms of [RFC5440], [RFC8231] and
   [RFC8281] are not used.  If there is no integrity protection on the
   session, then an attacker could create a path which is not subjected
   to the further verification checks that would be performed by the
   signaling protocol.

   Note that this specification adds the MSD field to the OPEN message
   (see Section 4.1.2) which discloses how many MPLS labels the sender
   can push onto packets that it forwards into the network.  If the
   security mechanisms of [RFC8231] and [RFC8281] are not used with
   strong encryption, then an attacker could use this new field to gain
   intelligence about the capabilities of the edge devices in the
   network.
END NEW

------