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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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:[e-mail]]
Sent: Thursday, October 01, 2015 6:22 AM
To: Stephen Farrell
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-teas-fast-lsps-requirements-01: (with DISCUSS)

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]<mailto:[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]<mailto:[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]<mailto:[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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>