Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01

["Andrew G. Malis" <[e-mail]>]

Sam,

Thanks for your comments. We (the authors) will await further review from
the IESG before taking any particular action.

Cheers,
Andy


On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman <[e-mail]> wrote:

>
> Hi.
> I am the assigned secdir reviewer for this draft on requirements for
> very fast GMPLS path establishment.
>
> This draft outlines scaling requirements for new applications of GMPLS.
>
> I'd like to flag this draft for particular review from the security ADs
> and recommend that the IESG consider a process question and get input
> from the sponsoring AD.
>
> So, for the security ADS:
> The security considerations section reads in its entirety:
>
> .  Security Considerations
>
>    Being able to support very fast setup and a high churn rate of GMPLS
>    LSPs is not expected to adversely affect the underlying security
>    issues associated with existing GMPLS signaling.
>
>
> however the draft talks about increasing the number of cases where GMPLS
> paths cross administrative boundaries and significantly increasing the
> scale of GMPLS applications.
>
> I don't think we have good security solutions for cases where we're
> trying to do PCE-like things across mutually suspicious or potentially
> hostile administrative boundaries.
> And yes it's reasonable to assume that there are business relationships
> in place here, but we also understand from our experience with BGP and
> other internet-scale services the limitations of that.
>
> I think significantly more security work is consider.
>
> On a general level, there's basically no justification for the
> requirements given.
> For example, the document talks about how cloud computing is an
> application that will drive these requirements.  The document neither
> talks about nor cites any explanation of  what it is about cloud
> computing that creates that need nor gives the reader any ability to
> evaluate whether the need is real.
> The depth of analysis is similar for all the other cited applications.
> We jump from very broad staments like "cloud computing, datacenters and
> data visualization will need this," to specific requirements in terms of
> requests per second.
>
> I'd particularly like to call out section 2:
>     2.  Background
>
>        The Defense Advanced Research Projects Agency (DARPA) Core Optical
>           Networks (CORONET) program [Chiu], is an example target
> environment
>              that includes IP and optical commercial and government
> networks, with
>                 a focus on highly dynamic and resilient multi-terabit core
> networks.
>                    It anticipates the need for rapid (sub-second) setup
> and SONET/SDH-
>                       like restoration times for high-churn (up to tens of
> requests per
>                          second network-wide and holding times as short as
> one second) on-
>                             demand wavelength, sub-wavelength and packet
> services for a variety
>                                of applications (e.g., grid computing,
> cloud computing, data
>                                   visualization, fast data transfer,
> etc.).  This must be done while
>                                      meeting stringent call blocking
> requirements, and while minimizing
>                                         the use of resources such as time
> slots, switch ports, wavelength
>                                            conversion, etc.
>
> I recommend that someone take a look at the material on that DARPA
> project and see how well the DARPA requirements align with the
> recommendations in this spec.
> I'm somewhat concerned that DARPA put together a research project and
> said "Hey we'd like these things," and now the IETF, without any
> significant independent analysis is rubber stamping that as our
> requirements in this space.
>
> I don't know that's what happened here, thus I have not copied
> [e-mail].
> However, DARPA's request should not represent an informed consensus of
> the IETF.
> I'd like to see the IESG evaluate whether we actually have done our own
> analysis here and whether there is an informed consensus  behind this
> document.
>
> Thanks for your consideration,
>
> --Sam
>