Skip to main content

Minutes IETF99: capport
minutes-99-capport-00

Meeting Minutes Captive Portal Interaction (capport) WG
Date and time 2017-07-18 13:50
Title Minutes IETF99: capport
State Active
Other versions plain text
Last updated 2017-07-30

minutes-99-capport-00
Note takers: David Dolson & volunteer?

CAPPORT Working Group
          IETF 99
          Prague
          2017-07-18
          15:50-17:50 Tuesday Afternoon session II
          Chairs: Erik Kline, Martin Thomson
          Materials:
          https://github.com/capport-wg/wg-materials/tree/master/ietf99
Martin:
    - dates for deliverables are in the past, and some of the milestone docs
    are probably not relevant - we want to deliver something.
(A/V is hard)
    - is minimum set OK?
David Dolson: need to notify non-http-80
Tommy Pauly: expect to interact with web pages
Martin: considers status code 511 to be dead until new information.

          Agenda
          Administrivia                   5   Chairs
          MVP                            20   Chairs
          Architecture                   20   Dave Dolson
            https://datatracker.ietf.org/doc/html/draft-larose-capport-architecture
Did anyone take notes while Dave was talking??
Tommy: if adopting, work in parallel, not waterfall.
Adam Roach: Low value in problem statement
Martin: adopt?
Margaret: discuss adoption after other slides & discussion
Martin: Mark Nottingham doesn't want to work on problem statement; so we would
incorporate the good parts into arch doc.

          ICMP                           20   David Bird
            https://datatracker.ietf.org/doc/html/draft-wkumari-capport-icmp-unreach
Lorenzo no-nametag: how to tell attacker session-ID vs. proper session-ID.
David Bird: can check quoted packet
David Dolson: session-ID help filter out duplicate messages
Lorenzo: ephemeral port ranges are not huge; not hard to guess
Dave Dolson: in arch doc we said worst case ICMP impact is going to API and
asking Tommy: want to keep ICMP simpler, not put a lot in ICMP no-nametag: I
don't understand how we say both the ICMP is a hint and also that API and ICMP
can be out of sync. Otherwise we need security on ICMP. If it is a hint, OK.
but if it gives more then there are security issues. Tommy: building on that, I
see your point, but I don't have a ton of sympathy for the complexity argument
bc today there is a web server that can tell me how much time, and can control
the enforcement point. We should be able to do an API that is as simple as a
web portal serving up a static/dynamic web page. Martin: <hat off> Some
feedback I got was (a) there are far too many bits & messages (maybe dest
unreach is enough), you allow provider to provide discriminatory services.
David B: That's what walled garden does. We shouldn't go there. Martin: we
should be very careful about talking about discriminatory services. We need to
be very careful about what we say, including social effects. David B: is this
applicable to ICMP? Martin: Yes, fine grained control my enable it. Dave
Dolson: if we bring more in scope, we could restrict the enforcement point to
having a single tier.

          PvD                            20   Tommy Pauly
            https://datatracker.ietf.org/doc/html/draft-bruneau-intarea-provisioning-domains
Martin: Do you mean that if there is non-capport PvD, do probing funny-business
is not required? Tommy: yes Margaret: some odd timing things. If you get
capport PvD, you can't send traffic until checking PvD API. Lorenzo: I'm not
optimistic we will get this soon. Realistically, until we get to HTTPS
everywhere, this might provide wrong incentives. Lorenzo: Do you really want to
wait until letting traffic use the network? Tommy: today, we wait for capport
probe to complete until allowing network access. David Bird: confused by flow:
what if PvD API is misconfigured or lying? Tommy: this is not a new thing;
capport defeating approaches happen today. Devices will consider the network to
be evil. Dorothy Stanley: How does the client trust the information? Or does it
not? Tommy: need more in-depth analysis. In this case, PvD is secure
connection. Assuming HTTPS. Eric Vinke: in ? protocol, a blob sent back,
advertise prefixes in the JSON. (I didn't understand this point) Martin: maybe
not giving security, just misconfiguration protection? David B: doesn't get rid
of probe. Tommy: if someone is browsing to a server they want to go to, it
isn't wasted. Pierre Pfister: in IPv6 it is generally accepted the RA is
trusted. Lorenzo: Can we ignore this problem? Tommy: yes David B: security is
provided by TLS. Do you present the cert to the user? Tommy: Yes, in demo, yes
we presented FQDN to user.

          API                            20   Mark Donnelly
            https://datatracker.ietf.org/doc/html/draft-donnelly-capport-detection
Eric Kline: in favor of the reduction. What might non-default networks in the
API mean? Mark: intended to provide different ways of accessing Eric: is there
overlap with PvDs Yes r Martin: the question is, with multiple PvDs, do you
need multiple networks at this layer? Tommy: no Martin: what is session token?
Mark: people seemed to want session token. o Lorenzo: can we update on demand?
Lorenzo: counting issues: when does client know it has reached limit: Maybe ask
at 80%? Dave Dolson: Please see my comments on the API wrt style of using GET
vs. POST and RESTful approach. David Bird: wrt counting... (missed this)

Martin:
    Three questions:
    1. for arch doc, do we want a milestone for architecture. Humming: in favor.
    2. is the document a good basis for the milestone? Humming: in favor.
    3. do we need milestone for the ICMP signal? Humming: divided: not clear.
    4. API document: do we need a milestone? Humming: in favor.
    5. Is this document a good basis. Humming in favor.
Probably will cut milestones back by removing survey and taxonomy. (Discuss
with AD)