Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 5

From: <[email-masked]>
Date: Wed, 14 Oct 2020 14:38:15 +0000

Re-,

Please see inline. 

Cheers,
Med

> 
> Section 5
> 
> We should probably say something about how the the call home channel
> is a potential vector for attack, with mitigation requests
> potentially causing the indicated device to be partially blocked or
> booted off the network entirely; mutual authentication of a trusted
> call home server, "a healthy dose of skepticism about the indicated
> attack" (or rather, local inspection of the indicated traffic), and
> involvement of the local administrator can mitigate the new risks
> that are opened up.
> This is related to what we currently have in the last paragraph, but
> we don't specifically discuss it as a new risk/attack vector due to
> this protocol.

[Med] Add this NEW text:

   The DOTS Call Home can be misused by a misbehaving Call Home DOTS
   client by arbitrary signalling legitimate traffic as being attack
   traffic, or falsifying mitigation signals so that some sources are
   disconnected or some traffic is rate-limited...

> 
> We might also consider referencing the security considerations of
> RFC
> 8071 (NETCONF/RESTCONF call home) since the "considerations not
> associated with server authentication" are likely similar.

[Med] The only paragraph that can apply is the one related to computation. That one is already echoed in the document.
The one about scanning does not apply as connections always at the initiative of the server.

> 
> There may also be some considerations when the indicated attack
> source-prefix is in a private or local-use address range -- the "in
> scope" check at the call home server doesn't mean much.

[Med] Added this text right after the NEW one provided above:

   ... Such misbehaving Call
   Home DOTS clients may include sources identified by IP addresses that
   are used for internal use only (that is, these addresses are not
   visible outside a Call Home DOTS server domain).  Such requests
   should be discarded by the Call Home DOTS server.  More generally,
   Call Home DOTS servers should not blindly trust mitigation requests
   from Call Home DOTS clients....

> 
>    Common precautions mitigating DoS attacks are recommended, such
> as
>    temporarily blacklisting the source address after a set number of
>    unsuccessful authentication attempts.
> 
> [I note that we used the term "drop-list" in RFC 8783.]

[Med] Indeed. Fixed. 

_________________________________________________________________________________________________________________________

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Oct 2020 16:25:17 -0700

Hi Med,

Also inline.

>    client by arbitrary signalling legitimate traffic as being attack

(nit) "arbitrarily", I think

> The one about scanning does not apply as connections always at the initiative of the server.

Thanks for checking!

>    from Call Home DOTS clients....

I like this (especially the last sentence), but can we check that purely
internal address cannot ever be the source of an attack (even in the
presence of, e.g., NAT)?  It is not intuitively obvious to me that always
discarding such mitigation requests is the right thing.

> > [I note that we used the term "drop-list" in RFC 8783.]

Thanks!

-Ben