int-area | Thursday 9:30-12:00 | 20.07.2017 | Prague | IETF 99 Scribe: Erik Kline [ Administrivia ] * new Note Well, well noted * agenda: yes, bashing: not so much * doc status update [ PROBE ] Ron Bonica * many name changes, eping -> xping -> probe * utility like ping, but better * ping doesn't always exercise the probed interface * ping shortcomings outlined * 2 new ICMP messages: * extended echo request * extended echo reply * probed node voluntarily adds extra information, including: * status of the probed interface * status of other interfaces connected * extended echo request * includes destination address identifying proxy interface * L flag, interface local to the box or directly connected * IIO: Interface Identification Object * can gather information across address families * security considerations and mitigations * topology gathering, vendor models * MUST NOT leak information about one VPN to another * document status * next steps * last call? /comments/ * Dave Thaler * name handling is UTF-8? Yes * needs to say sender has to normalize or receiver must accept and normalize or both for redundancy * if ifname > 255 octets, then truncate. might make a non-UTF-8 string must truncate at a character boundary /last call on the mailing list/ [ Congestion Notification Across IP Tunnel Headers Separated by a Shim ] Bob Briscoe * RFC6040 update * Problem #1 with ECN * diffserv and ECN have to propogate down and up * can change in transition * all tunnel nodes have to deal with ECN correctly * MUST decouple ECN and DSCP config * Problem #2 * original scope all IP-in-IP * now includes IP-in-IP with shims (other stuff in between) * survey table of IP-shim(-L2)?-IP * roughly 18 different protocols identified, yay us * status and next steps * is SFC really not applicable? * Teredo? /comments/ * Tal Mizrahi * nvo3 mailing discussing this * each encap RFC will need to have a section that discusses ECN propagation * can this draft define small set of options that? - already in the base specification - this says that tunnels with shim need to choose also * Sri Gundavelli * many of the protocols are control plane tunnel setup - they need to spec the ECN behaviour * David Black * we're going to last call this draft where it is in TSVWG and will announce that WG Last Call to the intarea list * let's double check we have all the right guidance in the tunnels BCP * Ron Bonica * MPLS isn't in the table - MPLS is already covered [ Guidelines for packet timestamps ] Tal Mizrahi * 2 main timestamps in use * text * packat (e.g. NTP) * text based * RFC 3339 * Packet timestamps * widely used * no common format * no common format for defining new format * goals * recommended timestamp formats * guidelines for spec'ing new formats * recommendations * 32bit NTP * 64bit NTP * 64bit PTP [IEEE 1588] * template for defining new formats * field options: number of bits, units * Epoch * wraparound semantics * synchronization concerns * optional control field * format * precision * epoch * era /comments/ * Bob Briscoe * tcpm is discussing timers and timestamps * one problem is units/resolution - is there a draft? * low latency TCP option draft * Gabriel Montenegro * 6lo working group has document needing review [ Discovering Provisioning Domain Names and Data ] Eric Vyncke * Multihomed hosts connected to different provisioning domains * PVD: RFC 7556 * multihoming in IPv6 * PA space from multiple providers * PVDs can help solve: * v6ops multihoming * homenet * alternative to traditional bind() * draft goals: * identifying PVDs * give additional information * PVD ID RA option * addition data * GET https:///.well-known/pvd * returns network information in JSON format * host behavior * keep PVD information separate from other PVD information * according to existing specs per-PVD * implementation status * Linux Kernel patch for RA processing * many more open source tools * Wireshark dissector * demo during hackathon: * OpenWRT * iOS * NEAT project * check it out at bits-n-bytes * next steps * feedback: yay /comments/ * Sri Gundavelli * relation to mif working group? - only use RA, simple * like this work, started prefix coloring * don't want that work to be wasted * previous docs should be consulted * Ted Lemon * support this work * not complete * host cannot currently signal support for PVD * Lorenzo Colitti * a few things went wrong with mif * shot in the head * this is a continuation of that work * implementors are showing up now with work * IPR on the DHCP parts was possibly an issue * this scope is more realistic * Bernie Volz * do need to consider doing what Ted suggested * or document the impact of sending this info to normal hosts - bring your device to bits-n-bytes and try it out - already in the doc * Bob Hinden * interesting work * concerned about connection to DNS - additional information is extra * Christian Huitema * signal to host to connect to fetch a page * might expose cookies * has privacy implications * connecting hosts can be tracked - MAY/SHOULD but it's optional * in practice it will be automatic and not up to the user * it would be better if this was more local * Tommy Pauly * important points, we should clarify * similar to what happens when connecting to a captive portal * connect to hosts on the internet to try connectivity * probably the PVD web server should be more local * Dave Thaler * rephrasing: how do you get the bag of properties? * resolve FQDN * route to it * might need the bag of info, circular dependency * Bob Hinden * agree with everyone who paraphrased me * have to make it so it does one thing * this relies on all kind of mechanisms to work correctly * perhaps without DNS, web, routing * Dave Thaler * it's a lot to put in RA or in DHCPv6 * Lorenzo Colitti * question is not about privacy * a router on the network can log captive portal checks * do need a privacy section saying how this is no worse * Christian Huitema * no worse that existing is a weak argument * Lorenzo Colitti * we will have private DNS * but connectivity probes are going to remain approximately forever * the network operator can track the existence of the client * the PVD ID gives you can anchor to which to bind other information * in the RA gives you atomically all the essential information * everything else is optional * you don't need to fetch the metadata * Christian Huitema * obviously we need privacy consideration but also mitigation * what's prevents the coffee shop from pretending they are Verizon? - PVD uses https and certification validation * the additional information contains info to aid validation * but then the metadata is not optional * Bob Hinden * HTTPS does not really mean truly talking to the right party * Tommy Pauly * primary goal of step one is to distinguish origins of config information * secondary information is "nice to have", but not necessarily to be trusted * aids in certain uses * but does not mean stronger trust is warranted * Ted Lemon * if able to say my service is free or fast you might be able to trick the host * operationally, you have to make it possible to reach the HTTPS server * from mif: because of legacy hosts, talked about RA container option * Pierre Pfister * earlier drafts were trying to do a lot of stuff * aiming for simple, implementable * Ted Lemon * ability to say PVD-aware vs non-aware information is important * we should ask for what we want, should be easy to specify - we're trying to keep it simple * Dave Thaler * previous comments that resolving the information is optional * how do I know it's authorized? you need to resolve it * contradictory statements * might be able to cache previous answer * Christian Huitema * the current spec is easy to defeat * I am skeptical * Tommy Pauly * validating prefixes not router addresses - list of prefixes e.g. RIOs * if it's only an identifier, don't make any other assumptions * if you need to validate anything then you have to fetch the extra data * otherwise it's just an opaque token different from others * Pierre Pfister * ambitious trying to trust the router * perhaps HTTPS is not a way to say this is Verizon/France Telecom * but otherwise it's TOFU effectively * David Schinazi * your RA can give you any DNS server, but you can override * advisory information is available * doesn't imply extra trust * Lorenzo Colitti * another option is a device can use another interface to try to validate the PVD URL information * not sure if this is written, but in theory is possible to do /next steps/ * recommendations to proceed? * Suresh: int-area AD hat on * we need review from 6man, ipsecme, shooting for a BoF is maybe best * Ted Lemon * IETF has tried for several years * mif was killed (for whatever reason) * BoF and charters would delay this work * perhaps request IESG to immediately charter a one-off working group * lots of discussion about mif versus new group vs other choices * Mark Townsley * agree with lots of what Ted said * when mif was "quickly closed" there was a message from Terry that any remaining items could be AD shephered * would like to see something like that to get this progressing quickly * we have line of sight to code getting written in the right platforms * Sri Gundavelli * this work should move forward * there is a strong relation to 5G slices * Gorry Fairhurst * we have vendor code and groups that could all benefit * either we need a group or we need to adopt it here * Bob Hinden * there's a robust discussion here, good sign for doing it here * Mark Townsley * an AD shepherded documents doesn't need a working group * hum for adoption * humming in favor of adoption. To be confirmed on the ML [ MPT Network Layer Multipath Library ] Gabor Lencse * MPT is a network layer multipath * uses GRE-in-UDP * tunnel IP version can be different from path IP version * stack diagram * packet mapping * per-packet * flow-based * combined * connection specification * control plane * MPT started using configuration files * connections added dynamically * keep-alives * data plane document * per-packet mapping * paths have weights * number of bytes sent per path is proportional to the weight * flow-based * identified by 5-tuple * packet reordering * order right delivery done at the receiver * reorder window size * max buffer delay * many papers published * elimination of stalling events on YouTube video playback * draft in tsvwg /comments/ * David Schinazi * motivation? - alternative to MPTCP * why use multiple interfaces, more throughput - one use case: 2 enterprise sites maximize throughput * datacenter or smartphones or? - datacenter * Dave Allan * using GRE and stripe packets, Huawei informational draft does the same thing * how are you different? - per flow-mapping when implemented will be different * not sure the use case per-packet, otherwise it's the same as what's already documented (RFC 8157?) * Gorry Fairhusrt * GRE-in-UDP was one of many ways * are people asking for this? - for now is a research project * how is this related to banana working group? - I'll have to get back to you * Mark Townsley * there are 100 different ways to tunnel and balance packets * try multi-link PPP over an L2TP tunnel * Please continue doing research and please continue publishing. But we don't think we need any standards track work on this [ SOCKS v6 ] Vladimir Oltenau * SOCKSv5 has many roundtrips * use case: "bond" 3G/4G/LTE and WiFi using MPTCP * improvements over SOCKSv5 * opportunistically sends as much data up front * can request proxy use TFO * extensible with TCP-like options * 0-RTT auth possible * initial data offset gives server indication of how much data to buffer * prototype available at github.com/45G /comments/ * Christian Huitema * how do you handle replay attacks? - TFO has the same issue, TFO is optional - outside the scope of the draft * Ben Schwartz * enthusiastic about bringing shadowsocks into the light * my team works on shadowsocks-based clients and servers * but this is also extremely dangerous and should not be allowed at the IETF * this protocol is “insecurable” - we only included UDP associate because of SOCKSv5 * SOCKSv5 also insecurable, but not intended to be used on the Internet * there are a lot more opportunities for improvement * David Schninazi * good work, SOCKSv5 needs a facelift * Tommy Pauly * agree it's not safe, but there are going to be more high latency links that are going to be safe/trusted; could be useful there * Ben Schwartz * we've been burned many times for trusting the link, especially WiFi * David Schinazi * IPsec was what we had in mind