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

From: Ray Hunter <[email-masked]>
Date: Fri, 03 Apr 2015 21:46:48 +0200

Apologies for the very late reply: change weekends.

> Daniel Migault <mailto:[email-masked]>
> 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

---

From: Daniel Migault <[email-masked]>
Date: Fri, 3 Apr 2015 21:53:32 -0400

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-masked]> wrote:

>   Daniel Migault <[email-masked]>
>  20 March 2015 20:55
> Hi Ray,
>
> 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.
>>
>     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.
>

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.

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

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