Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)
On Fri, 29 Jun 2018 17:46:35 +0100 STARK, BARBARA H wrote > Hi Denis, > You appear to have perceived events and statements different from how > others' have perceived these. > I don't find this thread accusing Juliusz of bad behavior to be an > appropriate way of addressing your perceptions. > As chair of homenet (your email was sent to homenet and babel), I would > appreciate an opportunity to talk to you directly (by phone / VoIP) to try > to better address your perceptions. I find trying to do this by email very > challenging. > If others share Denis' perceptions, please let the chairs know. > Thx, > Barbara It has been a month and a week since then and for clarity I find it necessary to follow up. Barbara, you had sent me an e-mail directly and thoroughly explained why in your opinion I was doing a wrong thing. I had studied that with attention. I had answered your message, at length, directly on 2 July and explained, as clearly as I could, which meaningful details you did not take into account from my point of view. Also I had asked my own questions, including if you still find my posts to the list(s) inappropriate given that input. I expected a reply, but it never came. I accept people have their own plans for their own time. However, in order to avoid further misunderstanding in the working group(s), please mind that from now on I am unlikely to engage in off-list discussions about this matter. I have already explained the problem on the list, several times over, and I have raised exactly the points I was going to raise. If Barbara or anybody else has anything to add, please do it on the list under your name, like I do. Thank you. -- Denis Ovsienko ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07
On Tue, 24 Jul 2018 22:14:30 +0100 Daniel Migault wrote > Hi Denis, > > Thanks for the feed back! The big read arrow symbolized the synchronization > between the zone hosted on your HNA and the DNS Public server on the > outsourcing infrastructure. This could be your ISP or any third party. One > of the motivation to outsource was to prevent DDoS attack on the HNA, so as > mention Ted, if your ISP is as reliable as your HNA you may use a > third party to host your zone. However, the HNA hosts the Hidden primary > and is expected to host the most up-to date content. When you switch from > one ISP to another, these ISP are hosting secondary servers and your hidden > primary are expected to be able to synchronize with these secondaries. As a > result the zone published on the Internet is expected to remain > synchronized. The problem by switching from one outsourcing infrastructure > to the other, is that information stored in cache resolver (NS) may not be > up-to-date for TTL seconds. As mentioned Ted, we expect that the hosting > infrastructure is able to host rel atively safely. Hello Daniel. The example I provided is a bit exaggerated on one hand (in that this is not what is typically and continuously going on in, say, 95% of home networks), but is not exaggerated on the other -- I would guess, at least a third of home networks face major outages at some point of their deployed life, and you probably want to design a naming solution that is able to survive it. There are so many ways for networks to go wrong: software bugs, hardware faults, lightning strikes, diggers and rodents damaging cables, operators connecting wrong cables to wrong ports and deploying wrong configuration onto wrong network devices and so on. When it happens in a managed environment, there is usually a sufficient amount of competent people around to detect and handle the failure -- myself having been one of those IT troubleshooters during one or another couple years. But it is not uncommon that replacing a faulty piece of non-top-priority hardware can take a month or more. Expectedly, a $20/month service does not come with the best SLA in the market. So going offline (or split) for long periods is a part of the problem space. Then, in a non-managed environment, simply put, you are designing a heating boiler for users that have no idea how heating works. What you, as an engineer, effectively have for the user interface is a couple knobs, a couple buttons and a few LEDs. So your design must not be fragile, must be able to fail safe, and must somehow communicate the reason or error code of the failure if it cannot repair or reset itself. Like, for instance, a PC that lights up different combination of diagnostic LEDs or beeps in a specific way when it cannot make it through the POST. The appliance communicates a complex problem in a simple way, so the user can hand it over. And the user does not want any boiler issues in the first place, because the boiler guy charges for his work. I am not suggesting how to design this DNS zone setup, but rather how to evaluate its fitness before the actual deployment. The two points above may be helpful for that. > I believe this concern might also be relevant to the dhcp option draft where > we explicitly had the discussion of an ISP providing the service. In this > draft the DNS Zone Template is a template that is expected to be provisioned > by the HNA. In other words, the template is not expected to contain all > elements. The template is mostly useful when the HNA is booting. As a > result, it is likely that there are very little changes over time and remain > the same over the time you switch from one ISP to the other. If not > up-to-date, the HNA may also update the template. > It would be nice if this DNS zone hosting migration would not involve the ISPs. For them this is an obvious technical pain with questionable returns, and they will naturally try to avoid it. As it has already been proven with mobile number portability, the only way to guarantee DNS zone portability would be through a law or government regulation. Most ISPs are just in a different business. -- Denis Ovsienko ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07
Hello group. What I was trying to say at the WG meeting was the following. Looking at the slide with the red arrow between a DNS server in the home network and a DNS server somewhere on the Internet, the following scenario immediately came to my mind. 1. A home network is connected to the Internet through an ISP A. Everything is synchronous and works. 2. The link to ISP A fails. 3. For the next month the home network remains half time disconnected and half time connected through ISP B. Regardless of the Internet reachability, devices come and go, and the network tries to update its zone. 4. The link to ISP A is restored and works for the next three months. 5. The user occasionally connects to ISP B in parallel, as a matter of habit. 6. Go to 2. Now, given the suggestion that the ISP maintains the zone, it would make sense to think what happens when the ISP's copy is no longer updated and the home network copy has changed. I have briefly looked through the I-D and have not found anything that would explicitly make sure that the zone cannot go split-brain. And if it goes split-brain, will it necessarily synchronize afterwards with no human intervention? Maybe those provisions are there, but I did not see them, in that case please disregard the comment. Feel free to use this input to improve the document, if it gives you any new ideas. -- Denis Ovsienko ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)
On Fri, 29 Jun 2018 17:46:35 +0100 STARK, BARBARA H wrote > Hi Denis, Hello Barbara. I hope you are well. > You appear to have perceived events and statements different from how > others' have perceived these. I agree there is some difference. I do not agree this automatically infers I am doing a wrong thing by trying to work through this difference. My goal is to clarify this situation for myself and other participants. > I don't find this thread accusing Juliusz of bad behavior to be an > appropriate way of addressing your perceptions. I am sorry to object, but I am doing my best not to accuse Juliusz, as much as is reasonably practicable, in the course of this discussion of facts and problems. If I may suggest, you might see it better after reading my messages with more attention. I agree some of those facts and problems are not really enjoyable to discuss. As just one example, the Babel DTLS specification is a 4 days old publicly available document and a few hours old Internet-Draft. It consists of 8 pages, including 4 pages of technical prose. The Babel HMAC specification that is not 7298bis (feel free to suggest a better term) is a few hours old, smaller, publicly available document and isn't an Internet-Draft yet as this is being written. It says "draft-ietf-babel-rfc7298bis" at the top (sic!). Those are facts. I have spared the participants of how I [subjectively] perceive those facts. You are welcome to verify the facts if you want. I emphasize the facts are not my perceptions. I am willing to listen if you tell me specifically what you find wrong. > As chair of homenet (your email was sent to homenet and babel), I would > appreciate an opportunity to talk to you directly (by phone / VoIP) to try > to better address your perceptions. I find trying to do this by email very > challenging. Your statement is correct, in that I had intentionally cross-posted to both mailing lists. This is because Babel security is meaningful for Homenet (I have been a reader of the Homenet mailing list for some time). I understand you are expecting a direct e-mail conversation with me to be difficult. I accept you may have reasons for this, but it seems to me you had not tried to reach me before, so it would not be right to put the blame on me. I am not putting the blame on you either. >From my own practical experience, e-mail works much better than phone: I can >take the time to think and to read my messages before sending to make sure >they say what was intended. If you insist anyway, we can have a voice/video >call, but if I see this causing even more misunderstanding to pile up, I will >have to switch back to e-mail. Hopefully that is workable enough for you. Have a nice day. > If others share Denis' perceptions, please let the chairs know. -- Denis Ovsienko ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] a clarification about cryptographic agility
Hello all. In yesterday's talk about Babel profile for homenet one of the slides briefly discusses protocol authentication. In particular, it mentions 2 mandatory to implement cryptographic algorithms as a requirement of RFC 7298. It should be noted that this particular requirement more belongs to BCP 201. In short, as soon as any cryptographic algorithm becomes involved, cryptographic agility becomes a concern and the problem is best addressed at the design phase by carefully picking two MTI algorithms. -- Denis Ovsienko ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
