Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications
On 22 Sep 2020, at 17:18, Stephen Farrell wrote: Hiya, On 22/09/2020 22:08, Lee, Yiu wrote: Hi Stephen, Thanks for the notes. Actually, we believe that there are good privacy reasons to randomize mac-address. This BoF isn't trying to "fix" randomized mac-address. On the contrary, we want the community to embrace it. In order to ease the anxiety for transitioning, we want to document what may break and propose best practice to transition to dynamic mac-address. Sure, I get that. However, we've seen a number of these efforts start thusly but end up being perceived to be partly trying to unwind the privacy benefits, so I think a good way to avoid that mis-perception is to also present the reasons for (in this case, MAC address randomisation) as fully as the description of the challenges caused. Right. it would not advance the case to introduce (or start using) something else bout the device that can be tracked and/or provide likability and thereby damage privacy in order to preserve the randomized MAC address machinery. Cheers, S. Thanks, Yiu On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell" wrote: That agenda and draft seem to make the seemingly common enough mistake of only focusing on what a new privacy or security mechanism breaks and glossing over the good reasons why people introduce these mechanisms. I hope the BoF proponents fix that because otherwise they may end up giving the impression that they would prefer to not see the privacy benefits (which I'd guess is not their goal at all). One reason those good reasons need to be included is that they constrain the kinds of additions that might make sense to better handle the new mechanism. We've seen a number of these kinds of reactions and I figure it'd really be better if the reaction were not to appear purely reactionary;-) If that were fixed, then there may be a better discussion of what, if any, additional things need doing. If that is not fixed, I'd not be surprised if the putative BoF were to devolve into a "it's bad" vs. "no, it's good" bun fight that won't really take us further. Cheers, S. On 22/09/2020 21:40, Michael Richardson wrote: Damn. Spelt captive-portal without the s again. Reposting, sorry for duplicates. I hate when WG names and list names do not match, and that we can't have aliases. And I think that reply-to gets filtered. Archived-At:
[homenet] -CoDel
On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote: Juliusz Chroboczek writes: PIE [...] lends itself better for implementation in existing hardware, or hardware with small modification. Could one of you please explain why? With the caveat that I have never worked with any of this hardware, this is my understanding: Basically, you can re-use the drop mechanism from RED and use the PIE algorithm as a (better) way to control the setpoints. This makes it possible to retrofit it in existing hardware. In fact I believe you can implement PIE entirely in the (software) control plane on (a lot of) gear that already knows how to do RED. Another factor, which as I recall was perhaps the strongest of the original motivations for PIE, is that PIE does nearly all its work on enqueue, whereas CoDel does most of its work on dequeue. In many hardware interfaces, especially at a head end where there are lots of queues and a simple hardware FIFO feeding the link, it turns out to be difficult/expensive to insert the computations CoDel does on each dequeue operation. -Toke ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet DaveO ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Introduction to draft-ietf-homenet-simple-naming
On 30 May 2018, at 19:39, Brian E Carpenter wrote: On 31/05/2018 08:53, Juliusz Chroboczek wrote: Well, let me invent something. I throw together my network and it names the printers as printer1 and printer2. Being a stickler, I decide to rename them as Printer 1 and Printer 2. I mess around and find a config file somewhere and manually edit it. Let me rephrase it: « For her birthday, I bought my girlfriend the nice printer she's been wanting. The network named it "Printer7839cf31". Since I love my girlfriend, I renamed it to "Mathilda's printer". Now she can no longer print. » It would be good if you could come up with a real example. This isn't going to happen in practice, (Giggle.) We'll see. As it says in every good shop: the customer is always right. Apple doesn’t think so and it may at least partially account for the fact that their products successfully auto-configure way more frequently than those of the competition. If there’s a lesson to be learned from this example it’s that either you don’t allow automatically-named things to change their names, or if you provide a user-friendly feature to change the name it “just works” and doesn’t break the associated function. I guess this means that if you rely on DNS to discover and use names, then you provide an update API and not allow “write-behind” to config files (if they exist in the first place). Now, if the name-changing auto-configuration functions are broken, then either there has to be a way to diagnose it (maybe only by the people who sold you the printer) and a way to revert to the prior configuration. That diagnostic function does in my view not have to be something easily done by the home user. DaveO Brian ___ 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] HNCP security?
On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote: It seems that the cryptographic literature needs to be rewritten now ... == Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. I would have thought it was the opposite: anything you can do with raw keys you can do with certificates. Raw keys cannot prove an assertion that a certain claimed name is bound to a certain key. In the case of self-signed certs you only get the advantages of having a data structure and code that is understood and well vetted, but with either a PKI or a web of trust you do get benefits from using Certs. You also get usage policy restrictions, which cannot be expressed with raw keys. On 9/18/2014 11:36 AM, Michael Thomas wrote: On 09/18/2014 08:31 AM, Markus Stenberg wrote: whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new X509, which is in nobody’s best interest). Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- email: rstruik@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 ___ 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] Unicast DNS within the Homenet?
On Sep 13, 2012, at 1:12 PM, Michael Thomas m...@mtcc.com wrote: On 09/12/2012 06:57 PM, Ted Lemon wrote: On Sep 12, 2012, at 9:02 PM, Mark Andrews ma...@isc.org wrote: My machines have names. Those names don't change as I move around the world. Random DHCP servers at coffee shops DO NOT have the ability to update the DNS entries for those names. They do have the authority to update the PTR records in in-addr.arpa and ip6.arpa namespaces. We're not talking about mobile IP here—we''re talking about naming in the homenet. The technology has existed for over a decade to do what you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for two reasons: one, I don't think it actually serves a real need, and two, it requires geek skills to set up, which most people don't have. But the second point is really a footnote to the first. Suppose the real need would be to have a viable way to get rid of putting raw IP addresses in upper level protocols? Ie, SDP, etc? That is a much broader architectural discussion than just DNS versus other naming systems. The whole question of how and whether A can tell B in an application protocol that he ought to talk to X in an independent communication and whether the expectation is that X=A can be made better, worse or just different when X is a name versus an address. I suggest we not talk about it - we risk ultimate regression to Godwin's Law. The Mike ___ 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] home networking of a different kind
On Mar 27, 2012, at 11:13 PM, Jari Arkko wrote: Not sure if this is on or off-topic for this working group but here's a recent extension to my home network setup: http://thingsonip.blogspot.fr/2012/03/smart-igloos.html I assume you need special protocols to get through - does that mean we need to add ICE to the homenet suite? :-) Jari ___ 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] Name resolution in the homenet architecture document
On Mar 13, 2012, at 12:23 PM, Ralph Droms wrote: On Mar 13, 2012, at 12:16 PM 3/13/12, Ray Bellis wrote: On 11 Mar 2012, at 15:22, Fred Baker wrote: ICANN is now selling dotless names. A name without dots has a defined behavior in most DNS resolvers; they find a way to further qualify them. Do we want to humor ICANN, or solve this? AIUI, the problem is more that on some operating systems a dotless name is first looked up in non-DNS based name spaces (e.g. NetBIOS). Only if those fail is it considered by DNS, with an optional search suffix. dotless name == pay-for-play TLDs ??? Just remember to dot your I(cann)s and cross your t(LD)s. Sorry, couldn't resist... - Ralph Hence on any particular network one cannot guarantee that the dotless name won't already exist in some other name space that then masks the (very expensive) DNS-based version. Ray ___ 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] [homegate] HOMENET working group proposal
On Aug 7, 2011, at 9:16 AM, Pascal Thubert (pthubert) wrote: Looks obvious, but is it? Yes. In one hand, we want the capability to reach anywhere we're allowed to from home. OTOH, if anything in my home is reachable from anywhere, we are back to the firewall paradigm. Why? You are still back to all the security disadvantages of firewalls - soft chewy inside, etc. Reachability does not convey access authorization. Devices must either protect themselves directly or delegate that protection to a proxy of some sort (*not* necessarily a firewall). There is an alternate model based on L3 overlays that was presented in various places under names such as route projection, community of interest or on-demand VPNs. That model forms dynamic overlays that act as L3 VLANs. Prefixes are no more injected in the main infrastructure but only projected within the overlay. This allows the model to scale with good mobility properties since an overlay separates the locator and the identifier, which BTW can be of different Address Families. sounds pretty complicated - if it requires manual configuration it may b a non-starter. I wanted to ask for a BOF in Taipei to discuss that model. Would anyone be interested? Not enough data here to judge. Pascal -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Roger Jørgensen Sent: Sunday, August 07, 2011 2:58 PM To: james woodyatt Cc: homenet@ietf.org; Fernando Gont Subject: Re: [homenet] [homegate] HOMENET working group proposal On Sun, Aug 7, 2011 at 3:18 AM, james woodyatt j...@apple.com wrote: snip In the context of the HOMENET working group, one imagines that restoring general end-to-end reachability is arguably a worthy goal. snip +1 :-) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ 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
