[Dots] Address scope RE: AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3

[[e-mail]]

Hi Jon, Ben, 

> > A bigger challenge that I see is how the Call Home DOTS client
> knows (i.e.
> > is configured in a trusted way) which Call Home DOTS server is
> > responsible for which set of source addresses that the attacks are
> actually coming from.
> 
> True, this seems "easy" if the call home client is the ISP but
> pretty hard otherwise.  Might be worth mentioning as well...
>

This is not specific to the call home, but applies for the base spec as well. See for example the discussion in 8811: 

==
The exact mechanism for the DOTS servers to validate that the resources are within the scope of the DOTS client domain is deployment specific. For example, if the DOTS client domain uses Provider-Aggregatable prefixes for its resources and leverages the DDoS mitigation service of the Internet Transit Provider (ITP); the ITP knows the prefixes assigned to the DOTS client domain because they are assigned by the ITP itself. However, if the DDoS Mitigation is offered by a third-party DDoS mitigation service provider; it does not know the resources owned by the DOTS client domain.
==

or 8782:

==
DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client's domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client domain is deployment specific.
==

Means to avoid maintaining "stale" information would also help (e.g., a network that rehome) or detecting a mismatch between the authorized IP prefix as seen by a client vs. what is seen by the server. These issues can be solved if we extend to data channel to register the IP prefixes "owned" by a domain and update them as soon a change occurs. Of course, the procedure to validate a prefix is in the scope of the domain claiming so would still be required, but unlike the signal channel, this will happen during idle time.

Cheers,
Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.