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

[Stephen Farrell <[e-mail]>]

Hiya,

On 09/08/15 16:04, Adrian Farrel wrote:
> Stephen,
> 
> Thanks for not placing a Discuss.

No problem. Had there been specific issues I had to raise, it
would have been a discuss. In this case, I had neither the
time to explore sufficiently nor enough background on this
topic, as you point out.

But frankly I think your criticism of my criticism is off the
mark. The point I made was that the lack of any evidence of a
security analysis having been done is unimpressive. That remains
the case. The examples were not claimed to be problems that need
fixing but questions about which one ought wonder when doing
this kind of thing. (As an aside, I don't think kite-flying is
a reasonable description of that, and I note that you don't
say that any of the possible issues I mentioned have in fact
been considered.)

As to whether my approach of honestly expressing my genuine
disappointment is the most productive, you do make a fair point.
In my partial defence, it is the case that I and others recently
had quite a difficult time dealing with a discuss on another
routing architecture document that suffered from what appeared
to me to a similar lack of security analysis, but nonetheless
that ought not have influenced my comment here. My apologies
to the authors/WG for that.

OTOH, it is a couple of decades past the time when doing basic
security analysis is expected as part of engineering good practice
in IT. I see no reason at all why routing should be some kind of
exception there. But I will really be delighted if someone sends
me a link to the WG archive where I find that all that work has
in fact been done but simply resulted in there being nothing much
new to mention.

Cheers,
S.

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