Re: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-flexi-grid-fwk-05: (with COMMENT)

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

Stephen,

Thanks for not placing a Discuss.

> - (Nearly a discuss) Section 7 refers back to RFC5920
> (from 5 years ago) and RFC6163 (presumably the 3 paragraph
> section 7) and also claims that there is "no substantial
> reason to to expect the security considerations to be any
> different." That's pretty unimpressive to be honest. Don't
> you think it'd be reasonable to expect that a new
> architecture, framework and set of protocols for high
> speed networks should today include a thorough security
> and privacy analysis done afresh and not simply referring
> back to previous work? For example, is it not likely that
> in some cases new IGP security primitives might be needed,
> or that virtualisation and data centre trends would mean
> that some additional isolation between different folks'
> data was desirable or that some kind of automated key
> management be finally required to be included from the
> start of the design of any new control plane? (This isn't
> a discuss as it's probably better to hold that kind of
> discussion for a next stage when some architecture or
> protocols are defined.)

I find your kite-flying tiresome in the extreme!
If you have specific issues or concerns that you can see need to be addressed
then please do raise them.
If you know of people who are control plane experts who believe that the
security of the GMPLS control plane has degraded or that new vulnerabilities
exist please do get them to engage on the TEAS working group mailing list
because those concerns will likely apply across all uses of GMPLS.
If you are aware of vulnerabilities in this new data plane you should make sure
that ITU-T SG15 is informed so that they can fix them and, at the same time, we
can look at how the control plane might be used to circumvent these issues.

But "is it not likely that in some cases new IGP security primitives might be
needed?" is a meaningless question without details. What cases have you in mind?
Why is a flexi-grid more in need of such security primitives than another
network? Why would the addition of such security primitives not be a generic
addition to GMPLS or even to the native IGP? In short, if you believe that new
IGP security primitives are needed you need to hurry to the OSPF and ISIS
working groups and ensure that those primitives are made available since their
applicability is surely wider than one particular data plane technology.

And you ask "or that virtualisation and data centre trends would mean that some
additional isolation between different folks' data was desirable?" Is isolation
a data plane feature? Are you concerned that there might be leakage between one
lambda slot and another? You do realise that the V in VPN means "virtual" and
that the packets all get jumbled up in one great big friendly Internet? Or do
you believe that the "additional isolation" should apply to the control plane as
well? And lastly, while optical data center connections are growing in
popularity, we may be a short distance yet from a flexi-grid data center with a
GMPLS back plane.

And lastly you ask "or that some kind of automated key management be finally
required to be included from the start of the design of any new control plane?"
And who could argue with this except to note that no "new control plane" is
being designed (which is why all the references to GMPLS etc. are made). The
fact is that a flexi-grid network is not substantially different from a lambda
network dating back 15 years. There are some minor differences in how the
optical spectrum is chopped up and this makes for very interesting economic
benefits achieved through flexibility and through maximal use of resources. But
the control plane modifications to turn a GMPLS control plane for an old-style
lambda network into a GMPLS control plane for  flexi-grid network are small.
This is not a new control plane.

So, when you say "Don't you think it'd be reasonable to expect that a new
architecture, framework and set of protocols for high speed networks should
today include a thorough security and privacy analysis done afresh and not
simply referring back to previous work?" I am bound to respond, yes, but I do
think it reasonable for an AD to read and understand a document before
commenting. This is not the new architecture or set of protocols that you claim
it to be, and the network is not of higher speed (necessarily) than what has
gone before.


Don't get me wrong. I think it is great that a Security AD worries about the
security present in our toolbox of routing and signaling protocols. But I think
you are aiming your worries entirely wrongly. The result of your poor aim is
that:
- you simply build resentment to any discussion of security
- you do not find the people who should be doing this work
- your concerns are lost because they are not heard

Can I suggest that you hold a BoF in Yokohama entitled "Security of the Routing
and Signaling Infrastructure". You can invite to this meeting the relevant
routing experts, and you can arrange for presentations from the security experts
who can show what the problems are.

There now. I have now spent much longer responding to your Comment than you
spent typing it. I am also much less inclined to listen the next time you have a
security concern about any of my documents. In short: a poor job done badly.

Thanks,
Adrian