Re: [Pce] Comparison of Encryption vs. Path Key Solutions for theCPSID.

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Sorry that I haven't been following this too closely.

Jean Louis made a couple of interesting points...

> > PCE WG members: thanks to provide your feedback on whether:
> > (1) You think that there is a need for such solution,
>
> Yes definitely, confidentiality is a key requirements in an inter-provider 
> context.
>
> > (2) You would prefer one solution (which one and why ?)
> > (3) You think that there is a need for both
>
> Answer to (2) and (3):
>
> It seems to me that we should end-up with a single solution so as to ease 
> interworking.

Of course, interworking is important and options are generally a Bad Thing 
(TM), but if the different solutions are beneficial in different 
environments then we can easily specify support for both options as 
mandatory. There will, in any case, be a policy decision at an domain border 
router to say how (and if) to process and encryption/path key.

So, for me, the question is whether there are different environments under 
which each of the options is preferable.

> IMO in an inter-AS MPLS-TE environment without PCEs, the paths
> will be loose anyway, so there will not be any confidentiality issue.

I am not sure. The point we are trying to make is that, in order to 
determine a viable (not to mention optimal) end-to-end path, it will have 
been necessary to compute the entire path. This may have been achieved 
privately by independent (albeit cooperating) PCEs.

In this case I think we are agreed that the full path would not be passed 
back to the ingress PCC for signaling, and so loose hops or strict abstract 
nodes would be used. But the question is what to do with the computed 
information so that it is not necessary to recompute when the signaling 
message enters the domain. One option, as you suggest, is to send it out to 
the domain border routers in anticipation of a signaling message (and 
potentially use a key to unlock it), a second option is to retain the 
information on the PCE and look it up using a key. The third option is to 
encrypt the path.

It seems to me that the first option requires the second to handle races, 
memory over-load, etc. So, in fact, the first option is an implementation 
optimization (but we may still need to make protocol changes to ensure that 
it is supported).

And my question reduces to:
Are there any circmstances under which ERO encryption is of value to us?

> If have some concerns regarding the cost of encryption, particularly for
> large paths (we need to think about future P2MP applications with a
> large number of hops...).

I am not so sure that the encryption of an ERO is so significant using 
today's technology. Indeed, one might equally argue that the cost of 
distributing a large number of paths for multiple destinations to several 
domain entry points could also be high.

> By the way, encryption approaches are really vulnerable
> to DoS attacks.

This sounds really important.
What you mean is presumably that we could waste a lot of CPU decrypting an 
ERO that is bogus.
But why is this more of a problem than receiving a bogus LSP setup request 
that causes us to do extra computation?
Or a Path message with a bogus path key that causes us to consult the local 
PCE for a non-existent path?

> Hence I would strongly favor the PKS solution. The optimization
> suggested, which consists of sending the computed path segment
> to the LSR in an unsolicited manner, just after the computation,
> sounds relevant and should be further investigated.

I think this is a valid application, but I would not want to see it made 
*the* standard technique since it gives me scaling worries for the future.

Thanks,
Adrian