Hello Mirja, > On Jun 17, 2016, at 8:14 AM, Mirja Kühlewind > <[email protected]> wrote: > adding tcpinc. How does this relate to working tcpinc?
in a tcpinc-deployment, MPTCP could use a derivate of tcpinc's key to authenticate new subflows. A draft similar to http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt would need to describe how the MPTCP-key is derived from the tcpinc-secret. Christoph > > Mirja > > >> Am 28.05.2016 um 10:32 schrieb Alan Ford <[email protected]>: >> >> Hi all, >> >> Following on from the discussion at the previous two IETFs, we have >> submitted two drafts proposing a way forward for resolving the loadbalancers >> issue (or in other words, separating tokens and keys), and in turn have a >> proposal for using TLS keying material with MPTCP. >> >> This proposal comes in the form of two drafts, to separate protocol changes >> (which we would be proposing for adoption into rfc6824bis), and TLS-specific >> extensions (which we would suggest are kept separate). >> >> The protocol changes >> (http://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.txt) >> propose an additional handshake mechanism to be negotiated in the >> MP_CAPABLE flags - the "G" bit, allocated to "application-layer". This means >> that MPTCP queries the application layer for Token and Key materials. This >> is negotiated by being offered by the initiator, and chosen by the answerer. >> >> Only tokens are sent on the wire, and these can be used to contain any >> information that could assist a far end to demultiplex connections (e.g. >> including routing data which would help front-end proxies). >> >> Minor changes that fall out of this also mean the IDSN, in that scenario, >> would be generated from the Token not the Key. >> >> Keying information may not be available at the SYN/ACK exchange, but will be >> provided by the application when available. Only once that has occurred can >> subflow setup continue. >> >> The TLS draft >> (http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt) shows >> how we can interface this proposal with TLS, using RFC5705 key export from >> TLS. This requires no changes to the protocol, but would register a new >> RFC5705 exporter with IANA. Exported keys from a TLS session would be passed >> to the MPTCP layer and used in the HMAC authentication algorithm. >> >> We would like to present and discuss these points in the upcoming interim, >> to see if there is consensus to add the necessary protocol changes to >> rfc6824bis. >> >> Best regards, >> Alan & Christoph >> _______________________________________________ >> multipathtcp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
