Re: [Teas] Stephen Farrell's Discuss on draft-ietf-teas-fast-lsps-requirements-01: (with DISCUSS)

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

Stephen,

OK, thanks, that makes your comment clearer for me.

How about a short sentence in the Security Considerations like: "If
encryption that requires key exchange is intended to be used on the
signaled LSPs, then this requirement should be included as a part of the
protocol design process, as the usual extra round trip time for key
exchange may have an effect on the setup and churn rate of the GMPLS LSPs".

Thanks again,
Andy


On Wed, Sep 30, 2015 at 7:10 PM, Stephen Farrell <[e-mail]>
wrote:

>
>
> On 30/09/15 23:52, Andrew G. Malis wrote:
> > Stephen,
> >
> > Note that this draft discusses GMPLS-based signaling for wavelengths and
> > TDM circuits, not layer 3 MPLS-based LSPs that are covered by your draft.
> > Layer 3 encryption cannot be used,
>
> Aside: Ours is not an L3 encryption, or else we're not using the same
> terms.
>
> > since the payload is arbitrary bit
> > streams typically at optical wavelength speeds.
> >
> > Does this address your comment?
>
> I don't believe so. Our draft isn't the point, but rather that any
> key exchange requires 1RTT and you can only do better if you remember
> things between peers for the next one. That does have impact on
> protocol design, esp. when an 1RTT is a significant duration. The
> only way to not have this impact on protocol design (that I can think
> of) is to not have any key exchange, which is also an impact on
> protocol design (in that case the impact is probably "confidentiality
> is not possible").
>
> Seems to me either is important enough to be noteworthy.
>
> S.
>
>
> >
> > Thanks,
> > Andy
> >
> >
> > On Wed, Sep 30, 2015 at 6:29 PM, Stephen Farrell <
> [e-mail]>
> > wrote:
> >
> >> Stephen Farrell has entered the following ballot position for
> >> draft-ietf-teas-fast-lsps-requirements-01: Discuss
> >>
> >> 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-teas-fast-lsps-requirements/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >>
> >> Are these reqs consistent with an additional RTT for key exchange?
> >> If not, why is that ok? 100 setups/second implies a real need for a
> >> 0RTT model for any key exchange. That has significant protocol
> >> design implications. I think you only need to note that, but that
> >> noting that is really needed. (This could for example affect the
> >> details of [1] or of later work similar to or built on [1]. Full
> >> disclosure: I'm a co-author of [1].)
> >>
> >>    [1]
> https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt
> >>
> >>
> >>
> >>
> >>
> >
>