-----Original Message-----
From: Anima <[email protected]> On Behalf Of Toerless Eckert
Sent: Tuesday 17 July 2018 00:30
To: Owen Friel (ofriel) <[email protected]>
Cc: Michael Richardson <[email protected]>; [email protected]; Eliot Lear
<[email protected]>
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg
On Mon, Jul 16, 2018 at 08:01:23PM +0000, Owen Friel (ofriel) wrote:
[ofriel] Are we making the assumption that all networks are well behaved and a
Registrar will actually reject devices it does not explicitly own? What about a
rogue network where the operator does not own the connecting devices but the
registrar accepts them anyway? That is the issue here.
I think Brians comment was abouut fixing BRSKI to re-include text we lost in
rev -08. The details of that text are not too relevant except IMHO giving some
examples, as it did in -07.
For the benefit of BRSKI becoming RFC, i would like to really only ask the
minimum necessary to fix this piece, but not draw it into the larger discussion
here related to your draft.
[ofriel] Agreed. I think the point Eliot and I are making is that the BRSKI
draft is fine as is (with that edit Brian pointed out) and does not need to
explicitly address the Wi-Fi SSID rogue network issue. And its worth pointing
out that the BRSKI draft does not preclude building a solution for that rogue
network SSID issue either (we have discussed this at length with Max). The
draft-friel-brski-over-802dot11 draft starts to touch on some mechanisms for
how to address the SSID selection issue, and that is a potential place to start
to document possible solutions.
As you point out, we can never be sure that rogue domains are not simply
accepting devices they do not own. But we can build secure pledges by making
MASA more secure and not hand out vouchers without more than the minimum
necessary logging. That is not saying that the MASA should do more than just
logging for every device, for example if the MASA supports both lightbulbs and
core routers, it's clear that the MASA policies could be different.
And this "sales" integration could be simply that the MASA requires some simple
identity for a domains registrar. E.g: verify some domains email, credit-card
number, ... something easily automated and good enough to track back the bad
guy with enough likelihood.
Cheers
Toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima