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

[Kathleen Moriarty <[e-mail]>]

Just one comment letting you know about progress on one of your points below.

Sent from my iPhone

> On Aug 9, 2015, at 11:04 AM, Adrian Farrel <[e-mail]> wrote:
> 
> 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.

We are working with Alia on security Webex sessions for the routing area.  Hopefully, we will be able to have one near term that stems from work on the SFC architecture draft that recently went through IESG review.  The other one will be at least 3 months out due to availability of the expert.  If something was done in Japan, then I'd like to make sure it was recorded for anyone who could not attend and didn't want to watch it when they are not at their best for learning (middle of the night).

Thanks,
Kathleen 
> 
> 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
>