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

[Daniel Migault <[e-mail]>]

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.

>
> 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.
    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?

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.


> 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.


>
> 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