> "Similarly, a wired broadband or 3G/LTE wireless connection to an ISP router > in the neighborhood has its own authentication and policy enforcement > happening at L2. "
I'm curious if we want to "assume" a particular type of broadband connection is in use, or do we want the Homenet solution to be "broadband-agnostic", and supply a robust solution without any knowledge of ISP/NSP connectivity method? If we make no assumptions, then our work is harder - if we "assume" certain types of links in place, then we may or may not fail in certain Homenet connectivity scenarios where our assumptions are incorrect, but the scope of our work will be less. Randy On Nov 25, 2011, at 12:43 AM, Mark Townsley wrote: > > Before we decide that we must have an IGP, that it must be cryptographically > secured, and that we have to tackle key distribution for it, I'd like to take > a step or two back from the routing protocol part of the equation. > > First things first, we have to detect that there is a device present, whether > it is a router or not, and if so what kind of router to router border we have > on that link so that we can apply a policy. If that policy allows sending and > receiving of addressing and routing information, from the perspective of the > routing protocol it has every thing it needs to start sending IGP packets in > the clear on that link. In terms of usability, the homenet cannot afford > crypto security or key exchange at every layer. I think we must inherently > trust security from layer 2 or physical, just like we do today between > routers and hosts (or nat-routers and nat-routers for IPv4) in the home. > > In practical terms, I think this means that if two routers are connected with > a physical link, that link should be trusted enough to send packets, in the > clear, which can at least identify what kind of router to router link this is > (e.g., local, ISP, etc.). The same applies if two routers are connected over > a secured wireless L2 link. Similarly, a wired broadband or 3G/LTE wireless > connection to an ISP router in the neighborhood has its own authentication > and policy enforcement happening at L2. > > In terms of UI, if one of those two routers is actually a PC or phone, we > shouldn't worry about the "pairing" issues much as there is enough user > interaction to sort that out (I do think that the state of the art could be > improved here, but that's for the UI wizards make better, not protocol hacks > like us). The most problematic real-world case today that comes to mind would > be in how to establish homenet routers that are connected via a wireless link > should be considered part of the same network. A link+button might be the > best way to make this happen for some routers, but others might prefer a UI > from a PC (e.g., the "airport utility") with passwords. I think the furthest > we can go here is to say that such a link must exist, and what the minimum > level of packet exchange should be allowed before discovering what type of > router-to-router link is present. > > - Mark > > > > On Nov 25, 2011, at 1:46 AM, Lorenzo Colitti wrote: > >> On Fri, Nov 25, 2011 at 01:27, Ted Lemon <mel...@fugue.com> wrote: >>> If one is a member of a homenet and an ISP connection already, and one has >>> a blank config, then you might assume that the one with the blank config >>> should join the existing homenet. What if they both have a config on them? >>> What if you're actually merging two separate networks? >> >> I think that's the idea. The user is saying "merge the two networks" in >> this case. >> >> Ok, so it would seem to me that to support that case then we need to either >> a) support multiple simultaneous keys in the IGP or b) provide a mechanism >> to tell a number of homenet routers that "the key to the IGP is changing". >> Both are non-trivial. Any other ideas? >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
