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

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

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

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Thursday, October 01, 2015 7:34 AM
To: BRUNGARD, DEBORAH A; Andrew G. Malis
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; The IESG; [e-mail]
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:[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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>