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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 05 Aug 2015 15:08:17 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ccamp-flexi-grid-fwk-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

- typo: trnaponders, I like it:-)

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Aug 2015 16:04:25 +0100

Stephen,

Thanks for not placing a Discuss.

> discussion for a next stage when some architecture or

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Aug 2015 00:52:32 +0100

Hiya,

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 10:56:26 +0100

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 9 Aug 2015 11:38:43 -0400

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 <[email-masked]> wrote:
> 
> Stephen,
> 

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

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 24 Aug 2015 13:01:19 +0200

Dear Stephen, Adrian

Thank you both for discussing this, please see inline for additional 
comments

El 11/08/2015 a las 11:56, Stephen Farrell escribió:
> (...) work resulting in the IETF will consist
Ramon> *relived* I believe this is the case.

> how my comment would be seen as over the top.

Ramon> As Adrian has surely pointed you out,  the draft is defining the 
fwk and req for the application of the GMPLS arch and protocols to a new 
switching capability / layer. Indeed, although the  technology/language 
etc., is cumbersome, it will result in relatively minor protocol 
extensions to existing protocols and not much different to what has 
already been done in the past with optical networks with fixed grid, 
OTN, SDH, etc.

We could extend the draft abstract for this, with something in the lines of:

OLD

This document defines a framework and the associated control plane
  requirements for the GMPLS-based control of flexi-grid DWDM networks.

NEW

Given the specific characteristics of flexi-grid optical networks and their
associated technology,  this document defines a framework and the
associated control plane requirements for the application of the existing
GMPLS architecture and control plane protocols to the control of flexi-grid
DWDM networks.  The actual extensions to the GMPLS protocols will be
defined in companion documents.

Thoughts?

thanks
Ramon