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
------
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
