Hi, Thanks for the comments. We have also discussed this issue during the meeting in Dallas, I will provide a version soon.
BR, Daniel On Fri, Apr 3, 2015 at 3:46 PM, Ray Hunter <[email protected]> wrote: > Apologies for the very late reply: change weekends. > > Daniel Migault <[email protected]> > 20 March 2015 20:55 > Hi Ray, > > Please see my comments in text. > > I think the description of the requirements and overall chain of events is >> excellent. Thanks for that. >> >> However I'm not particularly convinced by the security and authentication >> mechanisms, as the proposed text just seems to punt these to another >> transport protocol. >> > > Thank you for raising this point, but this is not the case. I need to make > the text clearer. When a renumbering occurs, the Hidden Master changes its > IP address, and has to provide the new IP address to the slave. This can be > done with DNS extensions or other layers. I will update the section 9.1.2 > to clarify this. > > Cool. Thanks. > > > >> I also don't see the recovery mechanism/ how to distinguish between a >> break before make event, and a make before break where the ISP's DNS >> servers may not be reachable at the moment of renumbering, or that a >> Homenet is simply not reachable for some time, and comes up "unnumbered" >> with no old IP, or that the Homenet never comes back at all. It seems to me >> that you could also end up hosting lots of cruft in the ISP servers, and >> there's a need for some garbage collection. >> >> I am not sure I correctly get the use case: > a) It seems to me you consider also the case where the slave is being > renumbered. I did not considered this point and assume these servers will > hardly renumbered. > > To be honest this should be a corner case. > > But it would be nice if the slave was also discovered via a DNS records > rather, than a literal, or cached IPv6 address. > Exactly, if the primary designates the secondaries with FQDNs it makes synchronization resilient to secondary renumbering. This has been suggested by Mark, and I have this on my local copy. > b) It also seems to me you consider a Homenet work that is removed > or not in used, and you wonder what happen to the zone? My understanding is > that it is similar a service you subscribed and you do not use. Do you mean > that we should state that after some time, the slave may remove its zone? > > Correct. It would be cruft removal. > > Can you please elaborate on the use cases you think we should comment? > Is sounds to me these considerations may not be related to renumbering, but > instead to general operations. > > They are indeed more general cases of changes. > > > >> I also expect we need some more limitations on when/why a slave would >> poll an unknown hidden master, otherwise it seems to me that we have a nice >> DoS vector/ amplification attack. A number of attack machines could spoof >> notification messages pointing to various ISP slave systems, all pointing >> to a common target victim "new" hidden master. >> > > This is mentioned in the NOTIFY RFC1996 in the security consideration. A > forged NOTIFY results makes the slave trigger a SOA query. These are small > paquets, thus the amplification factor is very small. RFC1996 qualify it as > a begnin DoS attack. But I agree I will comment on that. Actually I though > of writing a specific section on it. That will be done in the next version > anyway. > > > If we are not specifying the mechanism more precisely, then there should > be some warning that the slave should only try once to reach the new hidden > master for every incoming notify request. Ant retries should be triggered > from the hidden master sending a new NOTIFY request, not the slave retrying > independently. Otherwise you really are creating an amplification attack. > Well, in our case, the NOTIFY payload is authenticated. Eventually, the NOTIFY may be replayed multiple time during the valid time of the RRSIG. The slave is expected to have protections against replay attacks, especially given that NOTIFY are not expected to be sent in burst and multiple renumbering are expected o happen rarely. I think we consider this case then, and I will try to make it clear. > It feels to me like >> 1) we need a more reliable update mechanism between the hidden master and >> the slaves (to cover longer-term unreachability events, or a Homenet hidden >> master going off air permanently) >> 2) we need a more effective authentication mechanism for triggering >> updates, that is source IP address agnostic. >> > This is the case, as authentication is based only cryptographic keys. The > IP address is only used for reach-ability and is never used otherwise. > >> >> -- >> Regards, >> RayH >> >> > > > -- > Daniel Migault > Ericsson > > > -- > Daniel Migault > Ericsson > > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
