Hi Jon, On Mon, Feb 11, 2019 at 06:57:55PM +0000, Jonathan Hardwick wrote: > 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!)
I have been guilty of the same more times than I can count; what matters is that we get the work done, really. > Anyway, I think we have converged. Please see my proposals below, and > apologies for my tardiness. Indeed we have converged. > 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 Thanks. (It is wholly unsurprising that making actual wire-level changes here is to be avoided unless absolutely necessary, and this definitely does not qualify as absolutely necessary.) > ---- > > 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 That is very helpful, at least to me; thank you. > > ---- > > 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 Thanks! -Benjamin _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
