Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt

[Ray Hunter <[e-mail]>]

Apologies for the very late reply: change weekends.

> Daniel Migault <mailto:[e-mail]>
> 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