Subject: Re: [Plus] New Version Notification for draft-trammell-plus-spec-00.txt

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 5 Jan 2017 11:44:39 +0100

Hi all,

we submitted (just before Christmas) a new draft proposing a common wire image for UDP substrates. Based on the previous discussion on the list, the proposal follows the simpler approach of using a random serial number and highest number echo for basic diagnostics. In addition, we discuss further diagnostic information that could be provided by an extended header without proposing a extended header format yet. 
Stay tuned for further updates and please provide input or feedback! Thanks!

Happy new year!
Mirja

> Am 23.12.2016 um 15:28 schrieb [email-masked]:
> 
> 
> A new version of I-D, draft-trammell-plus-spec-00.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
> 
> Name:		draft-trammell-plus-spec
> Revision:	00
> Title:		Path Layer UDP Substrate Specification
> Document date:	2016-12-23
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/internet-drafts/draft-trammell-plus-spec-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-trammell-plus-spec/
> Htmlized:       https://tools.ietf.org/html/draft-trammell-plus-spec-00
> 
> 
> Abstract:
>   This document specifies a common Path Layer UDP Substrate (PLUS) wire
>   image for encrypted transport protocols carried over UDP.  The base
>   PLUS header carries information for driving a minimal state machine
>   at middleboxes described in [I-D.trammell-plus-statefulness], and
>   provides optional exposure of additional information to devices along
>   the path using the mechanism described in
>   [I-D.trammell-plus-abstract-mech].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 6 Jan 2017 17:40:03 +0000

Hi Mirja,

On 05/01/2017 10:44, "Plus on behalf of Mirja Kühlewind"
<[email-masked] on behalf of [email-masked]> wrote:
>we submitted (just before Christmas) a new draft proposing a common wire
>image for UDP substrates. Based on the previous discussion on the list,
>the proposal follows the simpler approach of using a random serial number
>and highest number echo for basic diagnostics. In addition, we discuss
>further diagnostic information that could be provided by an extended
>header without proposing a extended header format yet.

I've just finished reading the draft and was extremely pleased to see the
LoLa bit in the basic header.  An end-to-end integrity-protected marking
is definitely better than DSCP.

It also look pretty straightforward to add a couple of PCFs to the
extended header to support MTG signalling, which is nice.

A few editorial nits:
Sec 2.1, second bullet: "When multiplexing, it must ensure the PSN is not
already in use for the 5-tuple." -- you probably mean CAT instead of PSN?
Sec 2.2, second bullet: "It verifies the integrity of the information in
the PLUS Basic Header, using information carried in the overlying
transport." -- it's not clear which "information carried in the overlying
transport" you are referring to.
Sec 2.3.1, first para -- a bit hard to parse.

One meta-comment: how do you think the use of PLUS is negotiated by the
endpoints?

Cheers, t

>> URL:            
>>https://www.ietf.org/internet-drafts/draft-trammell-plus-spec-00.txt
>> Status:         
>>https://datatracker.ietf.org/doc/draft-trammell-plus-spec/
>_______________________________________________
>Plus mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/plus
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 31 Jan 2017 13:31:28 +0100

Hi Thomas,

sorry for the late reply and thanks for the feedback!

See below!

> Am 06.01.2017 um 18:40 schrieb Fossati, Thomas (Nokia - GB) <[email-masked]>:
> 
> Hi Mirja,
> 

Fixed in md file in GitHub.

> transport" you are referring to.

The idea here would be that the overlaying transport would e.g. have a hash that could be used to verify the header information. Basically this is a question about how the interface to the crypto engine would look like and we deliberately stayed a bit vague here. Should probably refine this for the next version. 

I’ve put an editor’s note in the md.

> Sec 2.3.1, first para -- a bit hard to parse.

Yes, that was broken. Fixed in the md now.

> One meta-comment: how do you think the use of PLUS is negotiated by the

Yes, this needs further discussion. The most likely case will be out-of-band knowledge (I know that this server on this port speaks plus) but we might also want to think about other discovery mechanisms but those things might actually be use case/higher protocol dependent.

Mirja