-----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

Reply via email to