* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Intarea Status Pages

Internet Area Working Group (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2010-Mar-23 —  
Chairs
 
 


IETF-99 intarea minutes

Session 2017-07-20 0930-1200: Grand Ballroom - Audio stream - intarea chatroom

Minutes

minutes-99-intarea-01 minute



          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
          
          



Generated from PyHt script /wg/intarea/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -