Re: [tcpinc] Revised version of TCP-ENO

[[e-mail]]

Martin Thomson <[e-mail]> writes:

> On 14 August 2015 at 11:05, David Mazieres
> <[e-mail]> wrote:
>> If we don't specify requirements for the session ID, then applications
>> will have to be knowledgeable about what encryption spec they are using.
>> That means if we get large SYN options down the line and massively
>> optimize TCPINC, applications won't be able to take advantage of it
>> automatically.
>
>
> Sorry, I missed an important word.  I have *no* problem with
> specifying requirements; I just have a problem with specifying
> mechanism with a requirement for that mechanism.

So what is your proposal?  Do you think TCP-ENO should specify the
mechanism or the requirement?  Right now, I think the draft is written
in an attempt to specify the requirements and leave the mechanism as
open-ended as possible.  I haven't seen any ideas on how to make it more
mechanism-agnostic.  Does this mean you'd favor dispensing with the
requirements and just specifying a mechanism?

> If you look at this in the abstract, how the session ID is acquired
> and defined can (and should) be opaque to an application using this.
> At some level, the requirement you want is an API one: the application
> MUST be able to acquire an identifier that is unique for the session.

Exactly.

> Also, given the other discussion, perhaps the model in RFC 5705 is the
> right one to use: don't expose a unique id, but provide an application
> the ability to extract a value, with the limitation that it be
> specific to that application.

Well, I'd say RFC 5705 tends towards the mechanism end of the spectrum,
since it tells you exactly what to feed into your PRF.  I don't know if
we want to make such assumptions about TCP-ENO specs.

David