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

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 1 Oct 2015 06:22:04 -0400

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 <[email-masked]>
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 <
> [email-masked]>
> > 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 <
> >> [email-masked]>
> >>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 1 Oct 2015 11:27:26 +0000

Hi,

I think the suggested sentence looks good. I’d prefer not to add the additional sentence on 0RTT as it seems too much in the context of the other requirements. Definitely it should be in the more detailed solution documents to come later.

Thanks Steven-
Deborah

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, October 01, 2015 6:22 AM
To: Stephen Farrell
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-teas-fast-lsps-requirements-01: (with DISCUSS)

Stephen,

Thanks,
Andy

On Thu, Oct 1, 2015 at 5:40 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hiya,

> exchange may have an effect on the setup and churn rate of the GMPLS LSPs".

s/may/will/

Cheers,
S.

>
> Thanks again,
> Andy
>
>
> On Wed, Sep 30, 2015 at 7:10 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>>
>>
>>> 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.
>> [email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>
>>>> email addresses included in the To and CC lines. (Feel free to cut this

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 1 Oct 2015 11:46:08 +0000

Ok- I'm convinced:-)
Andy - let's add this also-

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, October 01, 2015 7:34 AM
To: BRUNGARD, DEBORAH A; Andrew G. Malis
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-teas-fast-lsps-requirements-01: (with DISCUSS)

On 01/10/15 12:27, BRUNGARD, DEBORAH A wrote:
> Hi,
> 
> I think the suggested sentence looks good. I’d prefer not to add the
> additional sentence on 0RTT as it seems too much in the context of
> the other requirements. 

Like I said, I'm not blocking on that, but I will argue for it:-)

The full-RTT vs. 0RTT stuff is important to note up front as it
has a big impact on protocol design in cases where there is a
chance to get the 0RTT "win." And it may be that many folks are
not so aware of the possibilities, nor the associated complexity,
as well, so a signpost is a good idea I'd say.

Cheers,
S.

> Definitely it should be in the more detailed
> solution documents to come later.
> 
> Thanks Steven- Deborah
> 
> 
> 
> From: Andrew G. Malis [mailto:[email-masked]] Sent: Thursday,
> October 01, 2015 6:22 AM To: Stephen Farrell Cc: The IESG;
> [email-masked];
> [email-masked];
> [email-masked];
> [email-masked];
> [email-masked]; [email-masked] Subject: Re: Stephen Farrell's
> Discuss on draft-ietf-teas-fast-lsps-requirements-01: (with DISCUSS)
> 
> Stephen,
> 
> Thanks, Andy
> On Thu, Oct 1, 2015 at 5:40 AM, Stephen Farrell
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Hiya,
> 
>> 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".
> 
> 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 need not cost a full RTT and operate in so-called zero-RTT
> mode."
> 
> Cheers, S.
>> Thanks again, Andy
>> On Wed, Sep 30, 2015 at 7:10 PM, Stephen Farrell
>> <[email-masked]<mailto:[email-masked]>> 
>> wrote:
>> 
>>> 
>>> 
>>>> 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.
>>>> 
>>> 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").
>>> 
>>>> Thanks, Andy
>>>>> 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
>>>>> 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]