Apologies for the very late reply: change weekends.
Daniel Migault <mailto:[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.
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.
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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
