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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Adrian,

comments below.

> Am 14.03.2017 um 18:08 schrieb Adrian Farrel <[e-mail]>:
> 
> Hej Mirja,
> Thanks for the review.
> 
>> 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.
> 
> 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).

Okay.

> 
>> 2) Is the INTER-LAYER Object Flags registry really needed, given the
>> 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.

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.

> 
>> 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.
> 
> 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! Much better!

Mirja

> 
> Thanks,
> Adrian
>