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

Capport Status Pages

Captive Portal Interaction (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2016-Jan-04 —  
Chairs
 
 


IETF-100 capport minutes

Session 2017-11-14 1550-1750: Orchard - Audio stream - capport chatroom

Minutes

minutes-100-capport-00 minutes



          CAPPORT Working Group
          IETF 100
          Singapore
          2017-11-14
          15:50-17:50 Tuesday Afternoon session II
          Chairs: Erik Kline, Martin Thomson
          Materials: https://github.com/capport-wg/wg-materials/tree/master/ietf100
          
          Agenda
          
          Administrivia                   5   Chairs
          
          MVP                            20   Chairs
            - status of API document
            - report from Hackathon session
          
          Hackathon summary (some code done locally and remotely)
          Adopted an architecture, with new update
          There was an API document that was adopted but not updated
          - Darshak and Tommy offered to do API document work as editors for the
          WG document
          
          Architecture diagram overview from Erik.
          - Diagrams have been provided by architecture document, David Bird's
          ICMP slide summary
          - Erik put together a network architecture diagram.
          
              - Client talks through AP to switches, routers, etc, up to a login
              vendor which may be beyond the internet
          
              Questions: Where is the enforcement, where is the API, where is the
              initial web endpoint?
          
              What are the tokens? How does discovery work?
          
          
          ICMP (open discussion)         45   Kyle Larose
            https://datatracker.ietf.org/doc/html/draft-wkumari-capport-icmp-unreach
          
          
          
              UE tries to send out packets, and an enforcement block or allows
              packets. ICMP is how it sends the failure back to UE.
          
              The API server exists to check the UE status, etc. The API server
              needs to talk to the enforcement device.
          
          
              Problem: There needs to be an identifier to pass around to denote
              the device to the enforcement and API boxes
          
          
              Options:
          
              - L2 address/MAC address
          
              - L3 address/IP source address
          
              - Address + port?
          
              - Session ID
          
          
              Explicitly sent as ID from UE, or inferrered implicitly?
          
          
          Martin: Example of MAC address sent in URL has many interesting
          implications. The UE wasn't involved in sending that MAC address.
          The UE sent it's MAC address implicitly, and then the URL was created
          to send 'explicitly'. The token should be opaque if sent explicitly.
          Erik: Can also say Active/Passive options
          
          
              Hackathon: Implemented explicit L2, explicit L3, implicit L3
          
              Implicit was a lot simpler, but its less flexible. Note that if
              you're using implicit identifiers, the path/route must be the same
              for enforcement device and the API.
          
          
          Discussion:
          
          
          Architecture (update)          15   Kyle Larose
            https://datatracker.ietf.org/doc/html/draft-ietf-capport-architecture
            https://github.com/capport-wg/architecture
          
          PvD (update)                   15   Tommy Pauly
            https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains
          
          
          Hackathon
          ---------
          some code for detecting captive portals
          
          Open work
          ---------
          Before Aug 2018: decide between 7710 and PvD
          
          API draft
          ---------
          need authorization to make it an IETF document?
          Network diagram:
          - note that there might be a downstream client (tethered) from the direct
          client of the captive-portal network
          - PvD must be on-link, while DHCPv4 can be relayed
          
          ICMP
          ----
          - devices must agree on how to identify client. but how? layer2 / layer3
          identifier? opaque session ID?
          - should discuss security implications of non-opaque identifiers. e.g.,
          client can provide someone else's MAC address.
          - Hackathon experience
            - third option (implicit L3)
              - 1/2 the code size of others
              - but sent the wrong source IP address (confusion between API server
              and enforcement device)
              - erik kline: v4 or b6?
              - kyle larose: v4 only
              - erik kline: v6 has more addresses, could be even harder to get
              right
          - (darshak from cable labs): client should be involved; should have
          better security properties than implicit
          - kyle larose: but having client involved means the client can spoof
          - (rick?):
            - implicit still has possibility of spoofing; client can change its
            MAC address
            - three entities:
              - UE
              - API server
              - enforcement device
              - all three should be involved
          - Tommy from Apple: opaque identifier on client might require kernel
          plumbing. seems hard.
          - Pierre Pfister: what happens when a client chooses a new privacy MAC
          address?
          - Kyle: UE keeps track of identifierss
          - Martin:
            - clients likely to keep a single MAC address for the duration of the
            connection
            - enforcement device assigns UE an identifier
            - client receives ID in ICMP message
            - client can use ID when speaking to API server, etc
          - Tommy:
            - yes, more reasonable then trying to shim ID into every outbound
            packet
            - don't like session IDs in ICMP
            - why not just use the IP address assigned by DHCP?
          - erik: address is only meaningful on-link; devices beyond LAN may not
          understand this address
          - martin: may want to support enforcement points that are not on-link?
          - lorenzo: two enforcement points
            - one EP enforces internet-facing IP address matches expectation for
            UE's MAC address
          - Rick Taylor:
            - EP makes its own decision about the identifier
            - on-link could be L2
            - elsewhere could be L3
          - lorenzo: must have enforcement of MAC/IP pairing. otherwise, client
          A could "borrow" client B's IP address
          - kyle: security concern
            - party A logged in
            - party B wants to now if A is logged in; might query API server to
            find out
            - conclusion: must provide some constraint on size/semantics of
            session ID. e.g., large enough to be unguessable, and derived in some
            unguessable way
          - ek: what about v6 and new addresses?
          - rick(?): could go back to API server to change mapping
          - lorenzo: but then API server can limit the number of addresses used
          by client
          - tommy(?): if session ID is not included in packets, harder for network
          to identify client from a single packet
          - martin: can't include some network IDs in identifiers handed to client;
          e.g. operator may not want to disclose DSLAM port number to client
          - tommy(?): doesn't including port IDs make the
          enforcement-point/api-server divergence harder?
          - ben schwartz: trust problem with IP addresses as IDs; routers can be
          across multiple hops, with NATing in between. you can only say you trust
          the previous hop, not the end-client
          - lorenzo: with IPv4, we don't have a problem
          - rick: yes, we do
          - lorenzo:
            - ok, we don't have a /new/ problem; it works well enough
            - can we just solve under the assumption of "ipv6 prefix-per-host",
            and use the prefix as the identifier?
            - then most of the rationale for session IDs go away
          - ek: those are scope-limiting assumptions, right?
          - lorenzo: yes
          - kyle: should we document the use cases we're excluding; people might
          be implementing those use cases in ugly ways today
          - rick:
            - not all use cases are equally valuable; some are market
            differentiation without much practical benefit
            - two IDs: one ephemeral, one ongoing
            - ICMP response with token to use with API server
            - API server provides authorization token
            - on config changes, can use initial token to get a new auth token
          - lorenzo: second token gets me to yahoo? eh...
          - pierre(?):
            - don't want new transaction on every v6 address change
            - want some binding between client and some on-link device
          - ek: should spec require implementation to have some on-link devices?
          - pierre(?): port should be identity; then don't need to renegotiate on
          address change
          - kyle: don't want to preclude other lower layer implementations;
          e.g. wifi
          - mukesh (google):
            - for wpa-2 AP can identify client based on encryption state (pairwise
            encryption; other clients can properly encrypt for that same source
            MAC address)
            - for open networks, no clear solution
          - lorenzo (google), dan (hpe): OWE (RFC 8110) can provide similar
          properties for open networks
          - lorenzo: how about extension headers for session ID? (haha!)
          - tommy
            - if multiple hops: should /effectively/ have a single path; otherwise
            hard to do reliable enforcement
            - which desired use cases does session id enable?
          - kyle: need to support case where enforcement is the uncommon case;
          used only when service is discoonected?
          - martin:
            - API server does not to be colocated with enforcement device. need
            to support this design.
            - this is necessary for API server to answer "am i authorized"
            consistently with what ED will do
          - lorenzo: can we just say that IP address is unspoofable to API server?
          - kyle: what if we want to query over LTE, instead of wifi?
          - martin: lorenzo's suggestion effectively requires the two devices to
          be colocated (?)
          - ek:
            - "active client ID" is not in favor
            - implicit seems to have more positive discussion
          - tommy:
            - can't i just share my session ID with other devices?
          - ek: can use HMAC(mac address) in session token. avoids MAC spoofing.
          - tommy:
            - not spoof for traffic, but spoof queries to API server. figure out
            whether other client has paid
            - if session ID is just HMAC(ip, mac), then session ID hasn't added
            any security. anti-spoof comes from MAC/IP.
          - lorenzo:
            - don't want to facilitate different enforcement based on destiation
            address
            - changing tokens could be used to force different access to different
            sites
            - is this in the charter?
          - martin: not officially part of the charter, but is a "strong statement"
          - rick: it might be possible to do differentiated access even without
          changing tokens
          - lorenzo: but we don't need to facilitate that; if problems are found,
          we can address them
          
          Architecture Doc
          ----------------
          - Kyle
            - Adopted draft. Yay!
            - PvD vs DHCP (RFC 7710).
            - Is 7710 good enough? If not, do we improve 7710, or just move to PvD?
            - Is this an API endpoint or login page?
            - Doesn't tell us if there is a captive portal; could optimize network
            attachment if we know there's no captive portal
          - Tommy: We should better define what we might replace 7710 with
          - Lorenzo: We could just resolve the API/login-page question. Serve
          HTML/JSON based on HTTP accepts header
          - Rick:
            - designed to make the web work; not the Internet
            - should tackle Internet
          - Erik: how does PvD look as a solution for the Internet?
          - Rick: let me read up and get back to you
          - Martin:
            - will try to come to decision on list; if no conclusion on list,
            will do a video call
              -> not sure if this was in reference to identifier, PvD vs. DHCP,
              or both ???
            - open to obsoleting 7710
          - AD: need to discuss with Warren, since obsoleting 7710 isn't in the
          charter
          - Lorenzo: need to decide on identifier properties
          
          PvD
          ---
          - Tommy
            - don't have to reveal what we want to access, before deciding whether
            we want to use the network
            - get better information at attach time; eliminate need for active
            probes
            - important for iOS/Android (which often have other networks they can
            use)
            - by using RAs, we can updae client if things change
            - better put captive-portal indicator if you're doing captive-portal;
            clients will assume not-captive in absence of captive-portal indicator
            - could be evil, but clients can also "be evil". e.g., not join your
            network
            - what about indirecting through captive API URL vs. just putting into
            RA?
              - benefit: can provide more info; can provide that confidentially
              (TLS)
              - cost: extra network traffic
              - believe that benefit is worth cost; speak up if you disagree
            - is the API just for captive portal networks? or is this a more
            general facility?
              - static PvD properties
              - dynamic properties:
                - captive vs. not (motivating use)
                - carrier data plan status (possibly valuable future usage)
            - administrative: what goes into PvD doc vs. captive portal doc?
          - (unknown): v4 only networks will find it hard to swallow PvD (requires
          RAs)
          - lorenzo:
            - RA software on v4 will probably not be kept up-to-date
            - evil bit may or may not help
          - tommy: can't eliminate bad actors, but can help in networks run by
          good actors
          - lorenzo: ok; doesn't hurt
          - lorenzo: don't want to multicast on each client state change
          - tommy:
            - yes; there may be other dynamic properties that we want to multicast,
            though (hypothetical at this point)
            - could have some unicast push for "sub-PvD" (==per-client?) properties
          - rick:
            - RAs on IPv4 aren't going to take off
            - RFC 7710 cleanup just for IPv4? but PvDs for IPv6
            - in (hypothetical, revised) RFC 7710, maybe provide guidance for how
            to set up similar config on IPv6 (using PvD)
          - lorenzo: check IPR concerns
          
          ICMP
          ----
          - Tommy: three options:
            - "do-nothing option": prescribe that captive portal networks should
            send unreachable, administratively
            - new reason code
            - extension
          - kyle: benefit of new ICMP type: can send "about-to-expire" without
          interrupting traffic on older clients
          - lorenzo: captive portals are all open wifi networks; anyone could send
          the ICMP message. is this a fatal flow?
          - rick: session expiration shouldn't be at ICMP; it's control plane
          - ek: is destination unreachable with "captive portal enforced" valuable?
          - rick: yes, that's fine. it's "about to be unreachable" that's
          out-of-scope for icmp
          - tommy:
            - icmp great way to inform of open->closed transition
            - maybe don't generate icmp for clients who don't use the API server
          - rick:
            - destination unreachable is the wrong response, since you'll actually
            get somewhere (to the login server)
          - martin: anyone want to answer lorenzo's question?
          - lorenzo: is cleartext best we can do? this is greenfield, should we
          aim higher?
          - martin: icmp unreachable includes fragment of original packet; could
          secure by using hmac with token known to client and API server
          - kyle:
            - goal was not to require interaction with API server
            - prefer that HTTPS connection fails entirely, rather than scaring me
            with MITM warning
          - ben schwartz: is there enough entropy to prevent replay? (SYNs are
          short)
          - tommy:
            - if you can't talk to the API server, you're really just a legacy
            client
            - in fact, requiring API server interaction can help the network
            distinguish legacy vs. modern clients
            - are there _other_ reasons we should avoid interaction with API
            server?
          - kyle: can we improve ICMP without API server?
          - lorenzo: can ICMP help on its own? (for clients updated with ICMP but
          no API client code)
          - kyle: this is for legacy clients
          - tommy: UNREACH for internet access for legacy clients breaks things;
          those clients will no longer load the login page
          - kyle: oh, yes, that's right
          
          We will hold to a decision on identifier issue at London.
          
          



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