Subject: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-inter-layer-ext-12: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 14 Mar 2017 05:02:09 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-pce-inter-layer-ext-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Minor comments:
1) I guess the I flag in the INTER-LAYER Object is actually not needed as
the present of the INTER-LAYER Object already indicates that inter-layer
information is requested, but that is not an issue.
2) Is the INTER-LAYER Object Flags registry really needed, given the
limited amount of flag space???
3) Security Consideration: "Inter-layer traffic engineering with PCE may
raise new security
   issues when PCE-PCE communication is done between different layer
   networks for inter-layer path computation."
   This text is not very helpful as this section is meant to be used to
document these new issues.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Mar 2017 17:08:53 -0000

Hej Mirja,
Thanks for the review.

> information is requested, but that is not an issue.

I think that this is true in a PCReq, but it may be helpful for an implementation to always include the object but toggle the flag.
But in a PCRep the difference (while semantically the same) can have different inference. Thus...
If a PCReq has the object with I=1 and the PCRep has the object with I=0 we know that the responder considered providing an interlayer path, but did not. If, instead, the object is absent from the PCRep we can't be sure how seriously the responder considered the request (although the result is still a mono-layer path).

> limited amount of flag space???

I think so, yes.
The registry is to stop collisions.
I don't see how the size of the range makes much (any) difference.
If you don't have a registry, anyone can grab any bit and there is a requirement that everyone reads every draft to avoid collisions.

> document these new issues.

I'm trying to avoid saying "this should be obvious to one skilled in the art" since that always annoys me when the US patent office says it to me.

We could fill this out as...

OLD
   Inter-layer traffic engineering with PCE may raise new security
   issues when PCE-PCE communication is done between different layer
   networks for inter-layer path computation.  Security issues may also
   exist when a single PCE is granted full visibility of TE information
   that applies to multiple layers.

   Path-Key-based mechanism defined in [RFC5520] MAY be applied to
   address the topology confidentiality between different layers.
NEW 
   Inter-layer traffic engineering with PCE may raise new security
   issues when PCE-PCE communication is done between different layer
   networks for inter-layer path computation because information about
   the networks at different layers will necessarily be exposed in
   computation results.  Furthermore, a PCE in one layer might use 
   computation requests to "probe" for information about the network
   in the other layer. 
   
   Security issues may also exist when a single PCE is granted full 
   visibility of TE information that applies to multiple layers.

   In both cases cited here, the security concerns are to do with 
   exposure of information about a network to parties outside that
   network.  These concerns relate to the privacy of the commercial
   details of a network, but it should also be understood that 
   distributing information about networks extends the attack surface
   for those networks.

   Path-Key-based mechanism defined in [RFC5520] MAY be applied to
   address the topology confidentiality between different layers.
END

Thanks,
Adrian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 14 Mar 2017 18:18:28 +0100

Hi Adrian,

comments below.

> Am 14.03.2017 um 18:08 schrieb Adrian Farrel <[email-masked]>:
> 
> Hej Mirja,
> Thanks for the review.
> 
>> Minor comments:

Okay.

> If you don't have a registry, anyone can grab any bit and there is a requirement that everyone reads every draft to avoid collisions.

Given the flag field in this document is specified as reserved, any new doc that specifies a new flag must update this document. Hopefully the process works well enough to not cause collisions (I’m confident of that). 

The size matters, as I would expect that the number of documents that update this part is rather limited and therefore this is a viable and scalable approach.

However, if you’d decide to keep the registry, you should not specify the remaining flag part as reserved (otherwise you still have to update this document even if you have a registry). 

I would still recommend not to use a registry.

>   address the topology confidentiality between different layers.

Thanks! Much better!

Mirja

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Mar 2017 17:48:30 -0000

Hi,

That was quick!

> > If you don't have a registry, anyone can grab any bit and there is a requirement
> that everyone reads every draft to avoid collisions.
> 
> Given the flag field in this document is specified as reserved, any new doc that
> specifies a new flag must update this document. Hopefully the process works
> well enough to not cause collisions (I’m confident of that).
> 
> The size matters, as I would expect that the number of documents that update
> this part is rather limited and therefore this is a viable and scalable approach.
> 
> However, if you’d decide to keep the registry, you should not specify the
> remaining flag part as reserved (otherwise you still have to update this document
> even if you have a registry).
> 

There is a difference between "Reserved" in an IANA registry and "reserved" in the text.

I believe we have used a tried and tested wording (well, as long as I can recall) where:
- unassigned bits are described in the protocol as "reserved - must be set to
   zero, should be ignored"
- unassigned bits are flagged in the registry as "unassigned"
Such a formula never requires an update to the base RFC.

> > I'm trying to avoid saying "this should be obvious to one skilled in the art" since
> that always annoys me when the US patent office says it to me.
> >

OK. Perhaps that can get added as an RFC Editor note?

Cheers,
Adrian