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

[Stephen Farrell <[e-mail]>]

A bit more on this...

Adrian and I chatted on jabber yesterday and figured out the
disconnect here. I was interpreting this draft as the start of
some big new chunk of work in routing and hence bemoaning the
lack of a new security/privacy analysis. Adrian tells me though
that in fact the new work resulting in the IETF will consist
of a number of relatively minor extensions to existing protocols,
in which case the approach taken in the draft of asserting that
there's nothing much new here can be ok.

Perhaps I got somewhat taken in by some more marketing language
in the draft or something:-)

Anyway, I had another quick flick through the draft and the
following may have caused me to misinterpret what was going on:

- title: this reads like the start of a big new thing to me
- abstract:
  "This document defines a framework and the associated control plane
   requirements for the GMPLS-based control of flexi-grid DWDM
   networks."
  That tells me a whole new big chunk of work needs to be done
  which would require IMO a frech security/privacy analysis which
  was not done.
- intro, last para: same as the last point
- section 4 intro:
  "This framework is aimed at
   controlling the media layer within the OTN hierarchy, and controlling
   the required adaptations of the signal layer.  This document also
   defines the term Spectrum-Switched Optical Network (SSON) to refer to
   a Flexi-grid enabled DWDM network that is controlled by a GMPLS/PCE
   control plane."think
  Again that reads like there's a large new chunk of work to be done
  here, if "this framework" is a new thing and not an existing thing,
  which is unclear now I re-read it.
- 4.8.4: that still reads to me like a big new chunk of work, but I'm
  told it's less of a deal.

In summary, if this draft is the start of a big new chunk of work in
the IETF, then my comment stands - it should have had a serious chunk
of security/privacy analysis and I don't see evidence that it did.

If however I've misinterpreted the draft and it's really just teeing
up a set of relatively minor extensions to existing protocols, then
the "assertion that there's nothing new" approach taken here can in
some cases be justified, and if this is the situation then I can see
how my comment would be seen as over the top.

Cheers,
S.


On 10/08/15 00:52, Stephen Farrell wrote:
> 
> 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
>>
>