Hi Alan, adding tcpinc. How does this relate to working tcpinc?
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
