Kyle Rose <[email protected]> writes:

> I took a closer look at the API document just now. The first thing
> that jumps out at me is that since you are already providing part of a
> socket interface (via getsockopt/setsockopt), it may be helpful for
> interoperability to specify the errno values to be associated with
> particular protocol-level failure modes. E.g., if the application
> tries to set TCPENO_TIEBREAKER to 2, setsockopt should report EINVAL.

I'm sort of agnostic on this point.  Some error return is obviously
important, but using existing error numbers encourages implementations
to lump together the various failure modes, where some day it might be
deemed useful to expose more information.  (E.g., EPROTONOSUPPORT when
the socket is connected without TCPINC, vs. ENOTCONN when it is too
early to ask for a session ID.  But I think the socket errnos tend to be
less consistent across operating systems than POSIX ones.)

> The section on automatic configuration may be useful, but is the
> strategy outlined based either on data on general interference with
> TCP traffic by middle boxes or on empirical investigation of TCP-ENO
> itself across various types of networks?

It's based on empirical experience with tcpcrypt.  But more improtantly,
it's based on the *desired* experiments for TCP-ENO, and the fact that
the experiments will be most useful if most people do the same thing.

> I'm also assuming that if HMAC is an example of a PRF that the first
> argument to PRF is the key material. Not sure whether this needs to be
> spelled out.

Ah, good catch.  This is how it's typically written in the literature,
and indeed how it is used in, say, the HKDF RFC (RFC5869).  But I
realize that this is not specified in either RFC6234 or RFC2104, and
indeed that the example C code takes the arguments in the opposite order
(though it isn't quite comparable because there's a length argument,
too).

David

_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc

Reply via email to