Subject: [OPSAWG] AD sponsoring - draft-wkumari-dhc-capport-07

From: joel jaeggli <[email-masked]>
Date: Sun, 04 Jan 2015 13:32:18 -0800

Folks,

After some dicussion last year, I have agreed to sponsor
draft-wkumari-dhc-capport
(https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm
looking for feeback on right now is feedback from potential
implementors, either of client implementations of captive portal
detection or captive portals as to:

* Whether or not this represents a reasonable optimization,

* Have we gotten the security considerations right?

* Would you use it if there was general consensus to the approach.

Thanks
joel

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 18:39:22 -0500

> * Would you use it if there was general consensus to the approach.

I haven't seen any responses to this.  I don't expect you'll see any "we would use this responses," and you shouldn't predicate this work on seeing any.   I think the idea is fine, although I think the requirement that the URI use an address literal is unnecessary.   If the implementor wants to do that, they can, or they can just only answer DNS queries for the local domain until the user authenticates.   They'd have to do that to support the redirect anyway.

I think the document has way too much explanatory text.   It's good that it's there for now so that people can understand the problem that this draft purports to solve, but it should not be in the final version.   Just explain how to use DHCP and ND to send this option (I think supporting it in ND is worthwhile, because DHCP isn't really very useful in an IPv6 hotspot environment).

It would be nice to talk about ways to authenticate this, e.g. PKI or DNSSEC certs.

I think you should run it by some people with HTTP fu to make sure that you haven't missed any obvious gaps, and of course run it by somebody with HTTP security fu to make sure there aren't any security flaws that need to be addressed.

I would not object to you AD-sponsoring this.   It's not in-charter for DHC, nor for 6man.   You should get it reviewed in both places, not just in DHC.

You may find section 5.7 of RFC 7227 useful: it would be good to make sure that your use of the DHCP URI option format meshes with what RFC 7227 does.   I didn't notice a problem, but didn't look all that carefully.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 22 Jan 2015 21:43:54 -0800

On 1/22/15 3:39 PM, Ted Lemon wrote:
>> (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what
>> I'm looking for feeback on right now is feedback from potential 
> I haven't seen any responses to this.  I don't expect you'll see any
> "we would use this responses," and you shouldn't predicate this work
> on seeing any.   I think the idea is fine, although I think the
> requirement that the URI use an address literal is unnecessary.   If
> the implementor wants to do that, they can, or they can just only
> answer DNS queries for the local domain until the user authenticates.
> They'd have to do that to support the redirect anyway.
> 
> I think the document has way too much explanatory text.   It's good
> that it's there for now so that people can understand the problem
> that this draft purports to solve, but it should not be in the final
> version.   Just explain how to use DHCP and ND to send this option (I
> think supporting it in ND is worthwhile, because DHCP isn't really
> very useful in an IPv6 hotspot environment).
> 
> I think you should run it by some people with HTTP fu to make sure
> that you haven't missed any obvious gaps, and of course run it by
> somebody with HTTP security fu to make sure there aren't any security
> flaws that need to be addressed.
> 
> I would not object to you AD-sponsoring this.   It's not in-charter
> for DHC, nor for 6man.   You should get it reviewed in both places,
> not just in DHC.

Yeah this is inline with my assumptions, thank you.

> You may find section 5.7 of RFC 7227 useful: it would be good to make
> sure that your use of the DHCP URI option format meshes with what RFC
> 7227 does.   I didn't notice a problem, but didn't look all that
> carefully.
> 
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 11:23:58 +0100

> You may find section 5.7 of RFC 7227 useful: it would be good to make sure that your use of the DHCP URI option format meshes with what RFC 7227 does.   I didn't notice a problem, but didn't look a…

is this needed when you have 802.11u?

does it conflict or should it be integrated with the prefix properties in http://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00

what's this proposals relationship with MIF's PVDs?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Jan 2015 08:08:35 -0500

> is this needed when you have 802.11u?

I've never actually seen an example of 802.11u in the wild.   Have you?   What I see in the wild are layer 3 solutions based on spoofing.   It would certainly be worth investigating this question, but I think even if 802.11u did see wide deployment in large WiFi network scenarios, this would still be useful for the coffee-shop scenario.

> does it conflict or should it be integrated with the prefix properties inhttp://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00

It seems orthogonal, but it sounds like you think it's not, so it might be worth you exploring that a bit more!

> what's this proposals relationship with MIF's PVDs?

I think it's orthogonal.   This doesn't really change what a hotspot network looks like--it just makes it possible to flag a network as a hotspot network without any skullduggery.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Jan 2015 17:26:58 -0500

> I think the document has way too much explanatory text.   It's good that it's there for now so that people can understand the problem that this draft purports to solve, but it should not be in the…

I've made it quite a bit shorter, but I've left in *some* background
so that it's clear to the intended audience why this is a better
option than their current one. Some of the audience for this is people
who run Captive Portals, and so a little more text than a usual IETF
person will need is appropriate.

> It would be nice to talk about ways to authenticate this, e.g. PKI or DNSSEC certs.

I do have some text in here about TLS for the payments part, but I'm
unclear as to where else we would need to authenticate stuff.

> I think you should run it by some people with HTTP fu to make sure that you haven't missed any obvious gaps, and of course run it by somebody with HTTP security fu to make sure there aren't any sec…

Thank you, good point. I have already shown it to several people of
that ilk and they are happy.

> I would not object to you AD-sponsoring this.   It's not in-charter for DHC, nor for 6man.   You should get it reviewed in both places, not just in DHC.

Yeah. When I named the document I hadn't realized that simply using a
dhcp option isn't something that DHC does. This means that it has been
unnecessarily cluttering up their document queue - sorry!

> You may find section 5.7 of RFC 7227 useful: it would be good to make sure that your use of the DHCP URI option format meshes with what RFC 7227 does.   I didn't notice a problem, but didn't look a…

Yup, thanks. I *think* it's OK, but I'll poke Dan (one of the authors
of RFC 7227) and twist his arm ^w^w^w ask him nicely to have a
look....

Thank you for your feedback.

I've posted an edit buffer here:
https://github.com/wkumari/draft-wkumari-dhc-capport and will release
it once I've incorporated other comments too...
W

>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Jan 2015 10:20:29 -0500

On Fri, Jan 23, 2015 at 8:08 AM, Ted Lemon <[email-masked]> wrote:
> I've never actually seen an example of 802.11u in the wild.   Have you?

Not that I know of...

> What I see in the wild are layer 3 solutions based on spoofing.   It would certainly be worth investigating this question, but I think even if 802.11u did see wide deployment in large WiFi network scenarios, this would still be useful for the coffee-shop scenario.

I've just spent some time going through the .11u / WiFi Alliance
Passpoint stuff (200page PDF, sells for $199.00!), and it seems like
it would be overkill for many situations. It may be a good fit for a
large provider, willing to roll out all of the needed back end stuff,
etc but doesn't seem like a great fit for coffee-shop / doctor's
office / hotels we go to, etc. It also seems like it will be a long
time till this would be rolled out everywhere - the draft is simply a
DHCP option that should be trivial to add.

In addition, not *everything* is wireless - when I go to a hotel the
first thing I look for is the wired jack, because hotel wifi is often
less than brilliant.

> It seems orthogonal, but it sounds like you think it's not, so it might be worth you exploring that a bit more!

I had a look at it, it expired in Jan 2014, as a -00, so I'm guessing
it is not likely to progress. It didn't seem like it would really fit
well - I think you *could* assign a well known color to flag "you are
behind a CP", but I see an easy way to put in the URI, etc..

> I think it's orthogonal.   This doesn't really change what a hotspot network looks like--it just makes it possible to flag a network as a hotspot network without any skullduggery.

Yup.
This is really meant to be a *simple* solution that allows the captive
portal to tell the client where to go to authenticate.

W

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Jan 2015 10:31:01 -0500

> first thing I look for is the wired jack, because hotel wifi is often

Good point.

One thing I will say about this BTW is that you should treat DHCPv4 and DHCPv6 as distinct protocols, because the option formats are different, and I think it's potentially confusing to lump them together.   And mentioning DHCPv4 and DHCPv6 separately ensures that people won't think this is an IPv6-only proposal.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Jan 2015 10:51:12 -0500

[ -DHC to cut down on their clutter ]

> One thing I will say about this BTW is that you should treat DHCPv4 and DHCPv6 as distinct protocols, because the option formats are different, and I think it's potentially confusing to lump them t…

Good point, done, thanks.

Posted a new version!

W

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Jan 2015 11:00:48 -0500

> Good point, done, thanks.

Hm, I didn't mean to eliminate DHCPv6 entirely.   It's quite possible that RA is sufficient, but for completeness I think it would be better to have a DHCPv6 option just in case it's needed.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Jan 2015 11:20:00 -0500

> Hm, I didn't mean to eliminate DHCPv6 entirely.   It's quite possible that RA is sufficient, but for completeness I think it would be better to have a DHCPv6 option just in case it's needed.

I can easily put it back :-)
I've gone back and forth on the v6 DHCP case a few times. I think it
goes like this:

-00: DHCPv4 only
-01: DHCPv4, DHCPv6   [ DHCPv6 added by Paul E]
-02: DHCPv6, RA, DHCPv4  [ RA added as requested by Lorenzo C]
-03: DHCPv4, RA [ DHCPv6 removed after threat^w request from Erik Kline :-) ]
-04: DHCPv4, RA
-05: DHCPv4, RA, bits of DHCPv6 came back.
-06: DHCPv4, RA, bits of DHCPv6
-07: DHCPv4, RA, bits of DHCPv6
-08: DHCPv4, RA.

I personally like DHCPv4 and DHCPv6, but there seems to be some
religion around this stuff :-)
Supporting multiple option for v6 means need to provide guidance on
what to do when you get *different* answers in DHCPv6 and IPv6 RA. I
had text in -02 covering this, I can easily put it back.

The whole DHCPv6 vs RA topic is, um, interesting... there appear to be
some quite strong opinions around this :-)
I'll spin another version with both DHCPv6 and RA, and guidance on
what to do if you get both. This will no-doubt annoy some folk, but I
can leave the consensus call to Joel :-)

W

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Jan 2015 11:31:21 -0500

> can leave the consensus call to Joel :-)

The problem with RA as opposed to DHCPv6 is that we've seen that uptake of RA options is slow compared to uptake of DHCPv6 options.   But we can't _just_ do DHCPv6, because as you say there is some religion about DHCPv6, and so certain companies are slow to implement DHCPv6 client features, if at all.   I think the right answer in the case where one sends it and the other doesn't is to assume that whatever _was_ sent is definitive, since we can't assume that the source of the RA and the source of the DHCP service will necessarily be updated at the same time.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Jan 2015 12:39:48 -0500

On Tue, Jan 27, 2015 at 11:31 AM, Ted Lemon <[email-masked]> wrote:
> The problem with RA as opposed to DHCPv6 is that we've seen that uptake of RA options is slow compared to uptake of DHCPv6 options.   But we can't _just_ do DHCPv6, because as you say there is some religion about DHCPv6, and so certain companies are slow to implement DHCPv6 client features, if at all.

Yup. I've been in the middle of some of these discussions :-)
I've put back the DHCPv6, and made it clear that there are 2 DHCP
options (v4 and v6)

> I think the right answer in the case where one sends it and the other doesn't is to assume that whatever _was_ sent is definitive, since we can't assume that the source of the RA and the source of the DHCP service will necessarily be updated at the same time.

Actually, when I ended up doing was saying that devices should prefer
the URI in DHCPv4, then DHCPv6, then RA.
This gets around the problem of what to do if the CP *does* send
multiple URIs (e.g to support clients that only do DHCPv6 or RA) and
they are different.
W

---

From: joel jaeggli <[email-masked]>
Date: Tue, 27 Jan 2015 22:35:12 -0800

> multiple URIs (e.g to support clients that only do DHCPv6 or RA) and

it's also plausible that the process of obtaining the information is a
bit of a race between the two protocols, so you should be ok with the
client starting with whichever finishes first. likewise the poosibly
unfortunate case where both protocols are present but which you only
recived a hint from one.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Jan 2015 14:02:15 -0500

On Wed, Jan 28, 2015 at 1:35 AM, joel jaeggli <[email-masked]> wrote:
> client starting with whichever finishes first.

Yup.

In the doc I have:

[Ed note: This ordering is somewhat arbitrary - this order was chosen
   because this is the order I expect the code to be implemented by OS
   vendors, and I'd like the same behavior from newer and older devices
   to make troubleshooting easier.]

The reason I prefer this to "whatever finishes first" is that it is a
bit more deterministic and so easier to troubleshoot. I also don't
clients to connect to http://<uri-from-dhcpv6> one day, after an OS
upgrade, suddenly start connecting to http://<uri-from-ra>. In theory
(and if the CP operators is sane) the <uri-from-dhcpv6> ==
<uri-from-ra>, but...

I don't think that the actual ordering is as important as the fact
that there *is* a suggested ordering. If you'd prefer the "whatever
comes first" I'm happy to make this change - it's all just bits...

> likewise the poosibly

Well, the way the document is written, either you get the option or
you don't. There is nothing wrong with having DHCPv4, DHCPv6 and RA,
and only getting the option in any subset of these, you just follow
the preference rule to decide which to use (if you get it from
multiple and they differ).

Anyway, this document has now gone through 9 revisions and it's been
more than a year. I think we've wrung all of the review out of OpsAWG
/ DHC that we are likely to get - what happens next?

W

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Jan 2015 14:07:49 -0500

> (and if the CP operators is sane) the <uri-from-dhcpv6> ==

In practice it's always going to be RA-first, because DHCPv6 doesn't start until after RA.   And it's likely going to be non-deterministic whether it's RA-first or DHCPv4-first, rather than being a function of some implementation detail in the O.S.

So I think Joel is right that there's no benefit to insisting on an ordering.   I think you should just say that the ordering is indeterminate, and if different mechanisms give non-equivalent answers, this is likely to cause operational problems in practice.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Jan 2015 17:46:49 -0500

On Wed, Jan 28, 2015 at 2:07 PM, Ted Lemon <[email-masked]> wrote:
> In practice it's always going to be RA-first, because DHCPv6 doesn't start until after RA.

Oh. Huh. Yeah, that didn't occur to me :-P

> And it's likely going to be non-deterministic whether it's RA-first or DHCPv4-first, rather than being a function of some implementation detail in the O.S.
>
> So I think Joel is right that there's no benefit to insisting on an ordering.

I wasn't really *insisting*, more of a general statement  ("If the
device gets different URIs (for example, via DHCPv6 and IPv6 RA) it
should try them in the following order: DHCPv4, DHCPv6, RA."), but
happy to remove that.

>  I think you should just say that the ordering is indeterminate, and if different mechanisms give non-equivalent answers, this is likely to cause operational problems in practice.

Done!
"In order to support multiple "classes" of clients (e.g: IPv4 only,
IPv6 only with DHCPv6, IPv6 only with RA) the captive portal can
provide the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, IPv6 RA).
The captive portal operator should ensure that the URIs handed out are
equivalent to reduce the chance of operational problems."

Version -10 posted. This is a nice, round number...

W

---

From: Warren Kumari <[email-masked]>
Date: Fri, 30 Jan 2015 10:31:08 -0500

[ Top post ]

The only change in -11 was to fix Olafur's affiliation....

I think that this is cooked / ready to go...

W

W