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

["Adrian Farrel" <[e-mail]>]

Hi,

That was quick!

> >> 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.

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.

> >> 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!

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

Cheers,
Adrian