Subject: [dhcwg] 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: Ted Lemon <[email-masked]>
Date: Tue, 27 Jan 2015 10:31:01 -0500

On Jan 27, 2015, at 10:20 AM, Warren Kumari <[email-masked]> wrote:
> 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.

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.