Re: [homenet] Why do homenets need SD?
On 13/03/2013 23:47, Michael Thomas wrote: What I find most telling is that after 25 years, printers are still the canonical example of the need for SD. But printers have entire programs/wizards that support their existence, so they're really lousy as a canonical example. It would be nice for things to attach themselves to my net and not require their awful apps to be installed. Exactly. That's why the architecture needs SD, in a nutshell. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Naming and internationalization
On 14/03/2013 03:03, Andrew Sullivan wrote: In the event the homenet is accessible from outside the homenet (using the global name space), it is vital that the homenet name space follow the rules and conventions of the global name space. In this mode of operation, names in the homenet (including those automatically generated by devices) must be usable as labels in the global name space. Yes, but shouldn't there be a normative reference to IDNA? Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On Wed, Mar 13, 2013 at 10:45:22PM -0700, Michael Thomas wrote: The problem here is that you actually believe this. Stuart's description certainly matches what I have observed. What is it you thought was false? Note that he went out of his way to use Apple examples, so the cross-vendor issues that plague this sort of behaviour aren't an issue. (I'd like that not to be true, of course, but that's not directly relevant to SD issues.) A -- Andrew Sullivan a...@anvilwalrusden.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 03/14/2013 04:15 AM, Andrew Sullivan wrote: On Wed, Mar 13, 2013 at 10:45:22PM -0700, Michael Thomas wrote: The problem here is that you actually believe this. Stuart's description certainly matches what I have observed. What is it you thought was false? Note that he went out of his way to use Apple examples, so the cross-vendor issues that plague this sort of behaviour aren't an issue. (I'd like that not to be true, of course, but that's not directly relevant to SD issues.) The assertion that it is common. It isn't. It's a way to amaze your friends. It's also irksome that common assumes a uniformity of i's and airs as you mention. There is no inevitability to the status quo, and we shouldn't proceed from that assumption. We should get on with the job of defining requirements for the long run. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 03/13/2013 11:55 PM, Mikael Abrahamsson wrote: I know plenty people who do this (airplay), and I know others who would do this if they could get it working easily (they have one vendor TV and a different vendor smartphone which doesn't support a common protocol for the smartphone to tell the TV to start playing whatever was being watched on the smartphone). Apple Airplay works ok, but I only get it working between Apple devices. I'm sure there are other vendor specific protocols that do similar things. Let's put this into a different perspective: If service discovery and resulting address independence doesn't work, then it's going to be a pain to renumber. With SD, I imagine that changing addresses in the home (with PD etc) wouldn't impact the user experience in a fatal way, thus removing some of the need for ULAs (which I think is an ugly hack considering current state of RA handling in devices where it's all-or-nothing for putting a default route towards the RA announcing device). Things should be addressed by DNS or alike, and they should have unique names/identifiers. Never should an IPv4 or IPv6 address be used. SD needs to just work, and it needs to work in a routed home, and preferrably it should work from the Internet as well. Vision statement: I want to be able to use IPSEC to talk to everything in my home from whereever I am, and the authorisation to talk to my home devices should come from common key/cert management. This nicely circles back to what I was originally asking for: requirements. The problem with section 3.7.1 is that it immediately dives into a particular solution space without an iota of discussion of what we require the solution to actually provide. I for one am not comfortable without those requirements to say that a particular solution is right, especially when coupled with extraordinary claims that this is common when it is plainly not. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [86all] Bits-N-Bites Lab Open
event Thursday evening 19:00-21:00. Everything has been working very well in fact we have several implementations running already including: * eRouter * HIPNET * Buffer Bloat * HOMENET I don't take this to mean that HOMENET and HIPNET are interoperating? -- Michael Richardson -on the road- pgp7JLilvtKZr.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [86all] Bits-N-Bites Lab Open
While I was in the room I do not recall that we tried this, we certainly can throughout today. I will work with the participants below to post an update on our efforts. I received offline email that would be welcome. I assume these updates would be welcome to the larger HOMENET mailing list. Thanks, John = John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net = -Original Message- From: Michael Richardson mcr+i...@sandelman.ca Date: Thursday, March 14, 2013 9:14 AM To: HOMENET homenet@ietf.org Subject: Re: [homenet] [86all] Bits-N-Bites Lab Open event Thursday evening 19:00-21:00. Everything has been working very well in fact we have several implementations running already including: * eRouter * HIPNET * Buffer Bloat * HOMENET I don't take this to mean that HOMENET and HIPNET are interoperating? -- Michael Richardson -on the road- ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [86all] Bits-N-Bites Lab Open
On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson mcr+i...@sandelman.cawrote: I don't take this to mean that HOMENET and HIPNET are interoperating? We didn't try that. We expect a contiguous homenet network to work fine behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET won't be able to get much of use from a SADR implementation. Mixing and matching devices wil not work. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On Thu, Mar 14, 2013 at 05:40:44AM -0700, Michael Thomas wrote: The assertion that it is common. Ok. Instead of getting into a fight about an empirical matter best resolved by doing a study of human behaviour (a capability that is mostly probably outside our collective expertise), can we just say that SD is used by some significant number of people in some cases, and that it is useful? There is no inevitability to the status quo, and we shouldn't proceed from that assumption. We should get on with the job of defining requirements for the long run. Is there something about service discovery that you think we should not be doing? It sure seems to me like it is a friendlier answer than manual configuration. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [86all] Bits-N-Bites Lab Open
Will not work today or ever? Should we expect them to at some point? = John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net = -Original Message- From: Lorenzo Colitti lore...@google.com Date: Thursday, March 14, 2013 9:25 AM To: Michael Richardson mcr+i...@sandelman.ca Cc: HOMENET homenet@ietf.org Subject: Re: [homenet] [86all] Bits-N-Bites Lab Open On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson mcr+i...@sandelman.ca wrote: I don't take this to mean that HOMENET and HIPNET are interoperating? We didn't try that. We expect a contiguous homenet network to work fine behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET won't be able to get much of use from a SADR implementation. Mixing and matching devices wil not work. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On Mar 14, 2013, at 9:32 AM, Ted Lemon mel...@fugue.com wrote: So we have to talk about it in the architecture document, or the document will be irrelevant. I have been reminded to point out that all of the discussion I've been having here has been with my AD hat off. The above could certainly be interpreted as an AD statement, but that is not how I intended it. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 03/14/2013 06:32 AM, Ted Lemon wrote: On Mar 14, 2013, at 8:40 AM, Michael Thomas m...@mtcc.com wrote: The assertion that it is common. It isn't. It's a way to amaze your friends. It's also irksome that common assumes a uniformity of i's and airs as you mention. Michael, with all due respect, you are out to lunch here. It is how a lot of people connect their speakers to the device that they use to play recorded music. It is how a lot of people watch TV. It's true that this stuff is more commonly used in the younger generations, but its use is quite widespread, and will become more widespread over time. So we have to talk about it in the architecture document, or the document will be irrelevant. Recall that my initial point is that the arch document should provide more background, motivation and most especially requirements. There is *none* of that right now. My push back about common is against the notion that this is all self-evident. It's not. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 03/14/2013 06:30 AM, Andrew Sullivan wrote: Is there something about service discovery that you think we should not be doing? It sure seems to me like it is a friendlier answer than manual configuration. All I want is the document to say why we want it and what we want it to do. I keep getting told this is all self-evident which sets my bs detector off. Is this really too much to ask for? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Naming and internationalization
On Thu, Mar 14, 2013 at 08:25:38AM +, Brian E Carpenter wrote: Yes, but shouldn't there be a normative reference to IDNA? If so, we should also include a reference to the preferred syntax discussion in STD 13 or maybe to the hostname syntax. But sure. A -- Andrew Sullivan a...@anvilwalrusden.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 14/03/13 05:21, Stuart Cheshire wrote: There's been some discussion about service discovery. Anyone who prints wirelessly from their iPhone or iPad without typing in an IP address is using service discovery. Anyone who’s watched video on a web page on their iPad, and then tapped the screen to transfer the video playback to their television, without typing in its IP address, is using service discovery. Anyone who’s streamed music from their iPhone to their wireless AirPlay speakers, or controlled their TiVo from its iPad app, or shown a slide show from their phone on a friend's television screen, or given a university lecture by beaming their presentation wirelessly from their laptop to the video projector, all without typing in any names or IP addresses, has been using service discovery. This is all commonly done today, but generally only on the local link. We'd like similar ease of use in larger networks too. I recently submitted this draft: http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt snip very illuminating details Here at IETF, the records are added to the DNS manually by our capable network volunteers. The idea of the Hybrid Proxy is to populate the DNS namespace automatically, making Wide Area DNS-Based Service Discovery available to a broader community of users. I'm concerned that that basis of this whole discovery mechanism is the domain name DHCP option. The service discovery mechanism has now migrated to the DNS, so all services are potentially discoverable from anywhere; that's good. But the concept of what's local is now hung exclusively on the value of DHCP option 15. DHCP option 15 most be one of the most overloaded and least well characterised of any DHCP options. Lots of homenet-type installations will have it set to .lan or something similar. Some will set it to .local only to discover that the .local TLD has been usurped. It's used frequently as substitute for the domain name search list option but concatentating more than one domain with spaces, for clients which don't support the later option. It's somewhat succeeded by the FQDN option, and therefore not supplied. DHCPv6 doesn't have, AFAIR an equivalent, only the FQDN option. Now, we want to overload with yet another meaning. Is that wise? Wouldn't defining a new option be better? Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Why do homenets need SD?
Ah, that makes much more sense. That's true, however there are some existing solutions that partially work, and I don't think them bad. Limited, yes, but not bad. So it isn't crazy to think of extending them. Andrew On Thu, Mar 14, 2013 at 1:49 AM, Michael Thomas m...@mtcc.com wrote: On 03/13/2013 09:23 PM, Ted Lemon wrote: On Mar 13, 2013, at 8:26 PM, Michael Thomas m...@mtcc.com wrote: Mike, purposeful luddite It's worth noting that we _do_ need to serve the needs of people who buy and use modern devices, not just luddites, much as we may fondly prefer to be luddites ourselves. My point here all along is that there is no inevitability about the so-called status quo about the way things are named on homenets. This is still in its infancy and we should do the right thing rather than figure out how to hack on bad solutions to make them suck less. Mike __**_ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/**listinfo/homenethttps://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On Thu, Mar 14, 2013 at 06:45:32AM -0700, Michael Thomas wrote: All I want is the document to say why we want it and what we want it to do. I keep getting told this is all self-evident which sets my bs detector off. Ok. The -07 draft covers this in 3.7.1 for service discovery. Is the problem that it doesn't say what kinds of services are to be discovered? A -- Andrew Sullivan a...@anvilwalrusden.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On Thu, Mar 14, 2013 at 9:45 AM, Michael Thomas m...@mtcc.com wrote: On 03/14/2013 06:30 AM, Andrew Sullivan wrote: Is there something about service discovery that you think we should not be doing? It sure seems to me like it is a friendlier answer than manual configuration. All I want is the document to say why we want it and what we want it to do. I keep getting told this is all self-evident which sets my bs detector off. Is this really too much to ask for? It's a working group document. Feel free to contribute text as well as criticism. -K- Mike __**_ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/**listinfo/homenethttps://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
Hi, Let me jump-in from home appliance manufacturer perspective. (2013/03/14 9:41), Michael Thomas wrote: Recall that my initial point is that the arch document should provide more background, motivation and most especially requirements. There is *none* of that right now. My push back about common is against the notion that this is all self-evident. It's not. As Chris mentioned in his presentation, protocols and services become complex day-by-day, but users don't. We can memorize many IP address, domain names, or URLs to select/specify communcation endpoint. But we cannot expect our home customers to do so. Applications in home networks (including M2M applications like SEP2 but not limited to) naturally have their goal to communicate, but does not have a priori knowledge of the surrowinding environment. Thus they need some binding mechanism between a goal and communication endpoints that serve for the goal. In general, this kind of mechanism is called 'service discovery'. Hoping it helps the discussion. // Yusuke DOI yusuke@toshiba.co.jp ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?
-Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Tim Chown Sent: 13 March 2013 16:36 To: homenet@ietf.org Group Subject: Re: [homenet] Next steps for draft-behringer-homenet-trust- bootstrap? On 5 Mar 2013, at 17:52, Michael Behringer (mbehring) mbehr...@cisco.com wrote: Our draft shows a way to do that in a relatively simple and secure way. I believe this is a fundamental requirement in a homenet; there are other ways to more or less achieve this goal - that needs to be discussed. But we should have the discussion. If you have text to propose for the arch text, please do so. There will be cases where two homenets are adjacent, or where a visitor plugs in a device that doesn't belong to the homenet. We need to be able to control that. I suggest a subsection in the security section (3.6) to address this. This could sound something like: -- 3.6.6. Device ownership There must be a way to administratively assert whether a device belongs to a homenet or not. The goal is to allow the establishment of borders, for example between two adjacent homenets or between the service provider and the homenet; and to avoid unauthorized devices from participating in the homenet. The homenet architecture MUST support a way for a homenet owner to claim ownership of his devices in a reasonably secure way. This could be achieved by a pairing mechanisms, by for example pressing buttons simultaneously on an authenticated and a new homenet device. Or by an enrolment process, as described in [draft-behringer-homenet-trust-bootstrap]. -- Thoughts? Michael Tim ___ 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
Re: [homenet] [86all] Bits-N-Bites Lab Open
On Thu, Mar 14, 2013 at 9:25 AM, Lorenzo Colitti lore...@google.com wrote: On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson mcr+i...@sandelman.ca wrote: I don't take this to mean that HOMENET and HIPNET are interoperating? We didn't try that. We expect a contiguous homenet network to work fine behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET won't be able to get much of use from a SADR implementation. Okay, Im familiar with Bufferbloat :) whats HomeNET and HIPNET ?? and who sells this eRouter platform ?? I need to catch up here. Mixing and matching devices wil not work. ___ 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
Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?
On 03/14/2013 08:40 AM, Michael Behringer (mbehring) wrote: -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Tim Chown Sent: 13 March 2013 16:36 To: homenet@ietf.org Group Subject: Re: [homenet] Next steps for draft-behringer-homenet-trust- bootstrap? On 5 Mar 2013, at 17:52, Michael Behringer (mbehring) mbehr...@cisco.com wrote: Our draft shows a way to do that in a relatively simple and secure way. I believe this is a fundamental requirement in a homenet; there are other ways to more or less achieve this goal - that needs to be discussed. But we should have the discussion. If you have text to propose for the arch text, please do so. There will be cases where two homenets are adjacent, or where a visitor plugs in a device that doesn't belong to the homenet. We need to be able to control that. I suggest a subsection in the security section (3.6) to address this. This could sound something like: -- 3.6.6. Device ownership There must be a way to administratively assert whether a device belongs to a homenet or not. The goal is to allow the establishment of borders, for example between two adjacent homenets or between the service provider and the homenet; and to avoid unauthorized devices from participating in the homenet. The homenet architecture MUST support a way for a homenet owner to claim ownership of his devices in a reasonably secure way. This could be achieved by a pairing mechanisms, by for example pressing buttons simultaneously on an authenticated and a new homenet device. Or by an enrolment process, as described in [draft-behringer-homenet-trust-bootstrap]. In today's world access control is gated at L2 via wpa or similar. Are you suggesting that we have a L3 equivalent? In addition? In replacement? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [86all] Bits-N-Bites Lab Open
The eRouter is an Arris TG862 device, more info found here: http://www.arrisi.com/products/product.asp?id=79 Thank You, Chris Tuska Senior Network Engineer, Comcast National CMTS Operations \ IPv6 Project /phone/ 720.267.7511 /cell/ 720.560.6306 From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Outback Dingo Sent: Thursday, March 14, 2013 9:46 AM To: Lorenzo Colitti Cc: Michael Richardson; homenet@ietf.org Subject: Re: [homenet] [86all] Bits-N-Bites Lab Open On Thu, Mar 14, 2013 at 9:25 AM, Lorenzo Colitti lore...@google.commailto:lore...@google.com wrote: On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson mcr+i...@sandelman.camailto:mcr+i...@sandelman.ca wrote: I don't take this to mean that HOMENET and HIPNET are interoperating? We didn't try that. We expect a contiguous homenet network to work fine behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET won't be able to get much of use from a SADR implementation. Okay, Im familiar with Bufferbloat :) whats HomeNET and HIPNET ?? and who sells this eRouter platform ?? I need to catch up here. Mixing and matching devices wil not work. ___ homenet mailing list homenet@ietf.orgmailto:homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?
From: Michael Thomas [mailto:m...@mtcc.com] [...] In today's world access control is gated at L2 via wpa or similar. Are you suggesting that we have a L3 equivalent? In addition? In replacement? We need a solution to this problem. I think this is the first important thing to note, and so far it isn't noted (or I missed it). Which solution is open for discussion. Can we agree thus far? Then, the referenced draft [draft-behringer-homenet-trust-bootstrap] is what we were thinking about, high level. We're happy to work on a more detailed version of what we're proposing, but before we'd like to understand whether it's actually in scope or not? ;-) Michael ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [86all] Bits-N-Bites Lab Open
HOMENET is what I chose to call one of the implementations that is a result of some of the work in the same WG. HIPNET is an implementation of a DRAFT that was submitted to HOMENET in February (http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01). eRouter is specified by Cablelabs, more information can be found here (http://www.cablelabs.com/cablemodem/specifications/e-router.html) HTH, John = John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net = -Original Message- From: Outback Dingo outbackdi...@gmail.com Date: Thursday, March 14, 2013 11:46 AM To: Lorenzo Colitti lore...@google.com Cc: Michael Richardson mcr+i...@sandelman.ca, HOMENET homenet@ietf.org Subject: Re: [homenet] [86all] Bits-N-Bites Lab Open On Thu, Mar 14, 2013 at 9:25 AM, Lorenzo Colitti lore...@google.com wrote: On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson mcr+i...@sandelman.ca wrote: I don't take this to mean that HOMENET and HIPNET are interoperating? We didn't try that. We expect a contiguous homenet network to work fine behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET won't be able to get much of use from a SADR implementation. Okay, Im familiar with Bufferbloat :) whats HomeNET and HIPNET ?? and who sells this eRouter platform ?? I need to catch up here. Mixing and matching devices wil not work. ___ 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
Re: [homenet] [86all] Bits-N-Bites Lab Open
I incidentally note that cerowrt implements quite a bit of homenet's ideas, too. I have been too busy fixing bufferbloat to be able to follow latest developments, nor have I successfully made a case for cerowrt's more interesting ideas (mesh routing in particular) to the homenet groups. cerowrt for example, comes with a lightweight dhcp-pd implementation while the other groups are using very heavyweight stuff. I do hope that the hipnet and homenet groups adopt some variant of fq_codel in their codebases soon, and I do hope to take a look at the ospfv6 stuff the homenet group has done, particularly as to address distribution, as On Thu, Mar 14, 2013 at 3:34 PM, Brzozowski, John john_brzozow...@cable.comcast.com wrote: HOMENET is what I chose to call one of the implementations that is a result of some of the work in the same WG. HIPNET is an implementation of a DRAFT that was submitted to HOMENET in February (http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01). eRouter is specified by Cablelabs, more information can be found here (http://www.cablelabs.com/cablemodem/specifications/e-router.html) HTH, John = John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net = -Original Message- From: Outback Dingo outbackdi...@gmail.com Date: Thursday, March 14, 2013 11:46 AM To: Lorenzo Colitti lore...@google.com Cc: Michael Richardson mcr+i...@sandelman.ca, HOMENET homenet@ietf.org Subject: Re: [homenet] [86all] Bits-N-Bites Lab Open On Thu, Mar 14, 2013 at 9:25 AM, Lorenzo Colitti lore...@google.com wrote: On Thu, Mar 14, 2013 at 6:14 AM, Michael Richardson mcr+i...@sandelman.ca wrote: I don't take this to mean that HOMENET and HIPNET are interoperating? We didn't try that. We expect a contiguous homenet network to work fine behind a HIPNET (it will just get a prefix via PD and use it), but HIPNET won't be able to get much of use from a SADR implementation. Okay, Im familiar with Bufferbloat :) whats HomeNET and HIPNET ?? and who sells this eRouter platform ?? I need to catch up here. Mixing and matching devices wil not work. ___ 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 -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
In message 16704.1363267...@sandelman.ca, Michael Richardson writes: Mark =3D=3D Mark Andrews ma...@isc.org writes: I'm not a namedropper, but that doesn't sound like kosher DNS to me... sort of a weird split horizon. Mark It is quite common for the stealth masters to exist (not Mark listed in the NS RRset). It is also quite common for Mark recursive servers to have local copies of zones that are in Mark use locally but not be listed in the NS RRset. The update Mark protocol supports forwarding of signed UPDATE requests where Mark the forwarding server does NOT have the shared secret. Mark homenet CER (master) listed authoritative servers Mark rest of the world Mark Now if you want this to work with the CER turned off while you Mark are away and update to the zone to work then protocol work is Mark needed to get multi-master working. I think that you are saying that there is software work, not that there is standards work? The DNS model is a single master server. That server can be the CER or a master hosted elsewhere (ISP). Both have advantages and disadvantages. CER hosting: pro: the homenet is not dependent on anything external for local DNS resolution. con: you need the CER to always be on or else you cannot update the zone when you are travelling. ISP hosting: pro: The CER can be turned off when traveling. con: you require the local link and ISP server to be running to make changes to the zone. Now for travelling we could manually switch the server roles around. Multi-master (if defined) would do this automatically and allow for updates to the zone when partition whether that was due to a link failure or powering off of the CER due to travel. This last part requires standards work as it needs to be cross vendor. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
On 03/14/2013 02:09 PM, Mark Andrews wrote: In message 16704.1363267...@sandelman.ca, Michael Richardson writes: Mark =3D=3D Mark Andrews ma...@isc.org writes: I'm not a namedropper, but that doesn't sound like kosher DNS to me... sort of a weird split horizon. Mark It is quite common for the stealth masters to exist (not Mark listed in the NS RRset). It is also quite common for Mark recursive servers to have local copies of zones that are in Mark use locally but not be listed in the NS RRset. The update Mark protocol supports forwarding of signed UPDATE requests where Mark the forwarding server does NOT have the shared secret. Mark homenet CER (master) listed authoritative servers Mark rest of the world Mark Now if you want this to work with the CER turned off while you Mark are away and update to the zone to work then protocol work is Mark needed to get multi-master working. I think that you are saying that there is software work, not that there is standards work? The DNS model is a single master server. That server can be the CER or a master hosted elsewhere (ISP). Both have advantages and disadvantages. CER hosting: pro: the homenet is not dependent on anything external for local DNS resolution. con: you need the CER to always be on or else you cannot update the zone when you are travelling. ISP hosting: pro: The CER can be turned off when traveling. con: you require the local link and ISP server to be running to make changes to the zone. Now for travelling we could manually switch the server roles around. Multi-master (if defined) would do this automatically and allow for updates to the zone when partition whether that was due to a link failure or powering off of the CER due to travel. This last part requires standards work as it needs to be cross vendor. Mark, I am still confused as to whether there is anything new/unimplemented here too. If my CER, say, is the master, but my ISP runs the globally visible NS RRset on their servers, so far so good. But if we want my CER to *also* act as an authoritative server within my homenet so that, for example, it still works when my ISP link is dead, is that a problem? Of is this just some configuration voodoo that doesn't actually need standardization? I hadn't really considered it, but your post make me realize that the opposite scenario could happen as well: ie, the master is actually in the cloud somewhere, and my CER is one of its slaves which, again, would play authoritative on my homenet. Both scenarios are interesting. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?
On 03/14/2013 10:03 AM, Michael Behringer (mbehring) wrote: From: Michael Thomas [mailto:m...@mtcc.com] [...] In today's world access control is gated at L2 via wpa or similar. Are you suggesting that we have a L3 equivalent? In addition? In replacement? We need a solution to this problem. I think this is the first important thing to note, and so far it isn't noted (or I missed it). Which solution is open for discussion. Can we agree thus far? Well, it seems to me that we have a solution today at L2, at least for wireless which is the most pressing need. Am I missing something? Or are talking about remote access into your homenet? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 13 Mar 2013, at 22:45, Michael Thomas wrote: The problem here is that you actually believe this. You're right. I'm living in a fantasy world, where Apple shipped DNS-Based Service Discovery in August 2002, then went on make mobile telephones, tablet computers, and television set-top boxes that use it, even opened a chain of retail stores selling said products, and the Apple stock price skyrocketed from $10/share to as high as $40 or maybe even $50/share. (I could claim in my delusional fantasy world that the stock price went even higher than $50/share, but even my imagination is not that outlandish.) Of course the truth is that none of these products ever existed, and these days Apple is long forgotten, and most IETF attendees have never even heard of it. Right, Michael? Stuart Cheshire ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
In message 51424b9c.4060...@thekelleys.org.uk, Simon Kelley writes: On 14/03/13 21:22, Michael Thomas wrote: On 03/14/2013 02:09 PM, Mark Andrews wrote: In message 16704.1363267...@sandelman.ca, Michael Richardson writes: Mark =3D=3D Mark Andrews ma...@isc.org writes: I'm not a namedropper, but that doesn't sound like kosher DNS to me... sort of a weird split horizon. Mark It is quite common for the stealth masters to exist (not Mark listed in the NS RRset). It is also quite common for Mark recursive servers to have local copies of zones that are in Mark use locally but not be listed in the NS RRset. The update Mark protocol supports forwarding of signed UPDATE requests where Mark the forwarding server does NOT have the shared secret. Mark homenet CER (master) listed authoritative servers Mark rest of the world Mark Now if you want this to work with the CER turned off while you Mark are away and update to the zone to work then protocol work is Mark needed to get multi-master working. I think that you are saying that there is software work, not that there is standards work? The DNS model is a single master server. That server can be the CER or a master hosted elsewhere (ISP). Both have advantages and disadvantages. CER hosting: pro: the homenet is not dependent on anything external for local DNS resolution. con: you need the CER to always be on or else you cannot update the zone when you are travelling. ISP hosting: pro: The CER can be turned off when traveling. con: you require the local link and ISP server to be running to make changes to the zone. Now for travelling we could manually switch the server roles around. Multi-master (if defined) would do this automatically and allow for updates to the zone when partition whether that was due to a link failure or powering off of the CER due to travel. This last part requires standards work as it needs to be cross vendor. Mark, I am still confused as to whether there is anything new/unimplemented here too. If my CER, say, is the master, but my ISP runs the globally visible NS RRset on their servers, so far so good. But if we want my CER to *also* act as an authoritative server within my homenet so that, for example, it still works when my ISP link is dead, is that a problem? Of is this just some configuration voodoo that doesn't actually need standardization? I hadn't really considered it, but your post make me realize that the opposite scenario could happen as well: ie, the master is actually in the cloud somewhere, and my CER is one of its slaves which, again, would play authoritative on my homenet. Both scenarios are interesting. Apologies if I keep dragging the topic from theory towards running code, but it's really worth looking at what's in dnsmasq now, since it supports all these modes using existing protocols and software. Think of dnsmasq as holding a repository of local addresses. At the moment they are derived from DHCP leases or local configuration (/etc/hosts). In the future they may come from mDNS too. Firstly, dns acts a DNS server for all the machines on the homenet. For names out there it's just a DNS proxy, but for local names it answers DNS queries directly. That allows local names to resolve even on a disconnected net. Secondly, it acts as an authoritative DNS server fielding queries from the wider internet for the local names, so that they can be resolved anywhere, as long the relevant domain is delegated and the ISP link is up. Thirdly, it allows slaves in the cloud to request zone transfers, so supporting the model where the CER is not directly delegated to, either because of worries about DoS, or because its global address in insufficiently stable. I have this function working, using a standard DynDNS.org secondary DNS account. They run BIND, as far as I know. You are missing the point. BIND+DHCPD can do all the above too. It is the senario described as CER hosting above. I've been running that at home with BIND+DHCPD since before dnsmasq existed. What BIND, dnsmasq or any other server can't do is muti-master there is no specification on how to do it. DNSEXT punted this work over decade ago. Simon. I ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
In message 20130314222706.8339930dc...@drugs.dv.isc.org, Mark Andrews writes: In message 51424b9c.4060...@thekelleys.org.uk, Simon Kelley writes: On 14/03/13 21:22, Michael Thomas wrote: On 03/14/2013 02:09 PM, Mark Andrews wrote: In message 16704.1363267...@sandelman.ca, Michael Richardson writes: Mark =3D=3D Mark Andrews ma...@isc.org writes: I'm not a namedropper, but that doesn't sound like kosher DNS to me... sort of a weird split horizon. Mark It is quite common for the stealth masters to exist (not Mark listed in the NS RRset). It is also quite common for Mark recursive servers to have local copies of zones that are in Mark use locally but not be listed in the NS RRset. The update Mark protocol supports forwarding of signed UPDATE requests where Mark the forwarding server does NOT have the shared secret. Mark homenet CER (master) listed authoritative servers Mark rest of the world Mark Now if you want this to work with the CER turned off while you Mark are away and update to the zone to work then protocol work is Mark needed to get multi-master working. I think that you are saying that there is software work, not that there is standards work? The DNS model is a single master server. That server can be the CER or a master hosted elsewhere (ISP). Both have advantages and disadvantages. CER hosting: pro: the homenet is not dependent on anything external for local DNS resolution. con: you need the CER to always be on or else you cannot update the zone when you are travelling. ISP hosting: pro: The CER can be turned off when traveling. con: you require the local link and ISP server to be running to make changes to the zone. Now for travelling we could manually switch the server roles around. Multi-master (if defined) would do this automatically and allow for updates to the zone when partition whether that was due to a link failure or powering off of the CER due to travel. This last part requires standards work as it needs to be cross vendor. Mark, I am still confused as to whether there is anything new/unimplemented here too. If my CER, say, is the master, but my ISP runs the globally visible NS RRset on their servers, so far so good. But if we want my CER to *also* act as an authoritative server within my homenet so that, for example, it still works when my ISP link is dead, is that a problem? Of is this just some configuration voodoo that doesn't actually need standardization? I hadn't really considered it, but your post make me realize that the opposite scenario could happen as well: ie, the master is actually in the cloud somewhere, and my CER is one of its slaves which, again, would play authoritative on my homenet. Both scenarios are interesting. Apologies if I keep dragging the topic from theory towards running code, but it's really worth looking at what's in dnsmasq now, since it supports all these modes using existing protocols and software. Think of dnsmasq as holding a repository of local addresses. At the moment they are derived from DHCP leases or local configuration (/etc/hosts). In the future they may come from mDNS too. Firstly, dns acts a DNS server for all the machines on the homenet. For names out there it's just a DNS proxy, but for local names it answers DNS queries directly. That allows local names to resolve even on a disconnected net. Secondly, it acts as an authoritative DNS server fielding queries from the wider internet for the local names, so that they can be resolved anywhere, as long the relevant domain is delegated and the ISP link is up. Thirdly, it allows slaves in the cloud to request zone transfers, so supporting the model where the CER is not directly delegated to, either because of worries about DoS, or because its global address in insufficiently stable. I have this function working, using a standard DynDNS.org secondary DNS account. They run BIND, as far as I know. You are missing the point. BIND+DHCPD can do all the above too. It is the senario described as CER hosting above. I've been running that at home with BIND+DHCPD since before dnsmasq existed. What BIND, dnsmasq or any other server can't do is muti-master there is no specification on how to do it. DNSEXT punted this work over decade ago. The reason this is important to homenet and not the general enterpises is because people turn equipement off in homes when they go on holiday yet take their laptops and other equipment using names linked to the homenet with them. With enterprises these servers are always on even when everyone is on holidays and if they do turn the site fully off they are not expecting to update the zone while the site is shutdown. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117,
Re: [homenet] will CER's be globally authoritative resolvers?
On 03/14/2013 03:27 PM, Mark Andrews wrote: You are missing the point. BIND+DHCPD can do all the above too. It is the senario described as CER hosting above. I've been running that at home with BIND+DHCPD since before dnsmasq existed. What BIND, dnsmasq or any other server can't do is muti-master there is no specification on how to do it. DNSEXT punted this work over decade ago. I was pretty sure this scenario was really a configuration thing that didn't require any further protocol work, but I'm still sort of bugged by my CER answering authoritatively when it's not an authoritative server according to the root servers. Is that legitimate? Would that cause issues with, say, DNSSec? The CER is essentially spoofing my domain when you come right down to it, even if that's what I want it to do. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
On 03/14/2013 03:35 PM, Mark Andrews wrote: The reason this is important to homenet and not the general enterpises is because people turn equipement off in homes when they go on holiday yet take their laptops and other equipment using names linked to the homenet with them. With enterprises these servers are always on even when everyone is on holidays and if they do turn the site fully off they are not expecting to update the zone while the site is shutdown. Mark It's why I'm hoping that this gets captured in the -arch document. I'm still puzzling about whether it would be better for the master to be in the cloud or in the CER though. If the cloud is the master I can throw my CER in the trashcan and not lose anything which is a nice property. It's also the cloud's job to make a pretty web site to manage all of this. I trust them far more than router vendors to make useable UI's. On the other hand, I'd worry that trying to auto-populate a cloud master would be more difficult from the access control perspective: my CER can be more liberal since it can know whether a device trying to add a name has passed access control checks on my local network, say, where the cloud master has no clue about that (or, say, if it was on a guestnet or whathaveyou). There are probably a lot more considerations too. Maybe this does beg your multi-master question? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
In message 51425135.1080...@mtcc.com, Michael Thomas writes: On 03/14/2013 03:27 PM, Mark Andrews wrote: You are missing the point. BIND+DHCPD can do all the above too. It is the senario described as CER hosting above. I've been running that at home with BIND+DHCPD since before dnsmasq existed. What BIND, dnsmasq or any other server can't do is muti-master there is no specification on how to do it. DNSEXT punted this work over decade ago. I was pretty sure this scenario was really a configuration thing that didn't require any further protocol work, but I'm still sort of bugged by my CER answering authoritatively when it's not an authoritative server according to the root servers. Is that legitimate? Would that cause issues with, say, DNSSec? The CER is essentially spoofing my domain when you come right down to it, even if that's what I want it to do. Please stop using root servers when you mean parent servers. They are *not* the same. The root servers are only parent servers for tld. There are authoritative servers and listed authoritative servers. The two sets are usually the same. When properly configured listed authoritative servers are a subset of authoritative servers. When you have overlapping or disjoint sets there is a configuration error. Now all authoritative servers serve the same zone content modulo zone transfer delay unless one is running a split horizon configuration. One of the usual reasons for running split horizon is to handle RFC 1918 / ULA addresses where the public version of the zone matches the private version of the zone with the RFC 1918 / ULA addresses stripped out. Doing this is straight forward with RFC 103[45] DNS. It is a little more complicated with DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
On 03/14/2013 03:54 PM, Mark Andrews wrote: Please stop using root servers when you mean parent servers. They are *not* the same. The root servers are only parent servers for tld. You're right, my bad. There are authoritative servers and listed authoritative servers. The two sets are usually the same. When properly configured listed authoritative servers are a subset of authoritative servers. When you have overlapping or disjoint sets there is a configuration error. Now all authoritative servers serve the same zone content modulo zone transfer delay unless one is running a split horizon configuration. One of the usual reasons for running split horizon is to handle RFC 1918 / ULA addresses where the public version of the zone matches the private version of the zone with the RFC 1918 / ULA addresses stripped out. Doing this is straight forward with RFC 103[45] DNS. It is a little more complicated with DNSSEC. So the bottom line is that unlisted authoritative servers are ok even in the face of DNSSec. That's good news. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] will CER's be globally authoritative resolvers?
In message 514257fa.90...@mtcc.com, Michael Thomas writes: On 03/14/2013 03:54 PM, Mark Andrews wrote: Please stop using root servers when you mean parent servers. They are *not* the same. The root servers are only parent servers for tld. You're right, my bad. There are authoritative servers and listed authoritative servers. The two sets are usually the same. When properly configured listed authoritative servers are a subset of authoritative servers. When you have overlapping or disjoint sets there is a configuration error. Now all authoritative servers serve the same zone content modulo zone transfer delay unless one is running a split horizon configuration. One of the usual reasons for running split horizon is to handle RFC 1918 / ULA addresses where the public version of the zone matches the private version of the zone with the RFC 1918 / ULA addresses stripped out. Doing this is straight forward with RFC 103[45] DNS. It is a little more complicated with DNSSEC. So the bottom line is that unlisted authoritative servers are ok even in the face of DNSSec. That's good news. With DNSSEC you can prove the unlisted servers are giving you good responses. The comment about difficulties with DNSSEC was with respect to split horizon. You can't just strip out records. You also need to regenerate RRSIG (as the signatures will no longer match the RRset) and potentially generate new NSEC/NSEC3 record chains when all the records at a name have been stripped out. This is not impossible to do. BIND already strips out and regenerates all the DNSSEC data with for certain configuration. Stripping out additional records would be straight forward. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: 14 March 2013 17:43 To: Michael Behringer (mbehring) Cc: Tim Chown; homenet@ietf.org Group Subject: Re: [homenet] Next steps for draft-behringer-homenet-trust- bootstrap? On 03/14/2013 10:03 AM, Michael Behringer (mbehring) wrote: From: Michael Thomas [mailto:m...@mtcc.com] [...] In today's world access control is gated at L2 via wpa or similar. Are you suggesting that we have a L3 equivalent? In addition? In replacement? We need a solution to this problem. I think this is the first important thing to note, and so far it isn't noted (or I missed it). Which solution is open for discussion. Can we agree thus far? Well, it seems to me that we have a solution today at L2, at least for wireless which is the most pressing need. Am I missing something? Or are talking about remote access into your homenet? No, it's not primarily for remote access. Even if we have something, the architecture doc should describe that this is an issue and needs to be addressed, and which solutions fit (including existing). But I think the need goes beyond wireless. If I have visitors, I may not like it if they plug in a device into the Ethernet socket in the guest room, and the device has full access to everything. I think we need a simple way to accept/deny a new device onto the network, independent of the media type. Michael ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
