On Thu, Jan 22, 2015 at 6:39 PM, Ted Lemon <[email protected]> wrote: > On Jan 4, 2015, at 4:32 PM, joel jaeggli <[email protected]> wrote: >> 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. > > 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'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 security flaws that need to be > addressed. 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 all that carefully. 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 protected] > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
