Minutes IETF99: intarea
minutes-99-intarea-01

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://<pvd-id>/.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