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.