Warren Kumari <[email protected]> wrote:
> Yup. We need input from captive portal vendors, captive portal operators,
> operating systems, applications, security folk, etc. Jim Martin and myself
> are part of the IETF NOC team and so we know some of the hotel CP folk, but
> we will also chat with the IAOC folk. But, yes, this is going to need lots of
> outreach -- I really like the ISOC angle...
I find that many captive portals that screw with DNS don't stop after you
authenticate, and so will continue to break DNSSEC even afterwards. The Bell
Canada DataValet CP which is deployed at many hotels and conference centers
is like this, and it also failed (I suspect: core dumped) when the reply had
AAAA records.
So this work fits into ISOC's Deploy 360 on IPv6 and DNSSEC for this reason.
I know that I previously said that the milestones were good, but I realized
that I was wrongish:
We need to publish a problem statement and security analysis first, (and do
it quickly), and get it out. At that point, one can actually say, "Hotel XYZ
is not BCPabc compliant", and the developers will have something to actually
beat their marketing people with. The threat that an operator will kick a
supplier out over a performance specification (that's the NAFTA/CETA and
probably TPP term) can be a real threat.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature