Thanks,
probably better to use the high frequency meeting options we have
this week than extending this thread too much right now. I guess
my highest level point is that i could see benefit in using the wifi
case you folks want to drive to build out document(s) for some
generic pieces we're missing like cloud registrar (BRSI is just a stub IMHO),
and really try to have the wifi doc only do the wifi specific piece -
and inherit any components we could equally use for non-wifi scenarios from
such shared additional docs.
Cheers
Toerless
On Tue, Jul 17, 2018 at 12:55:23AM +0000, Owen Friel (ofriel) wrote:
>
>
> -----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
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
