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

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

Stephen,

I'll make the change as soon as I get the go-ahead from Deborah.

Thanks,
Andy

On Thu, Oct 1, 2015 at 5:40 AM, Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 01/10/15 01:33, Andrew G. Malis wrote:
> > 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
>
> s/should/needs to/ is correct I think
>
> > 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".
>
> s/may/will/
>
> I'd add a mention of 0RTT mechanisms just in case too, e.g. "It
> is possible to amortize the costs of key exchange over multiple
> exchanges (if those occur between the same peers) so that some
> exchanges need not cost a full RTT and operate in so-called
> zero-RTT mode."
>
> Note though that the above are non-blocking. If you make your
> originally suggested change I'd clear the DISCUSS.
>
> Cheers,
> S.
>
>
> >
> > 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>