>> 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). > > 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.
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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
