Subject: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30

From: Stephen Farrell via Datatracker <[email-masked]>
Date: Thu, 14 Mar 2019 08:33:34 -0700

Reviewer: Stephen Farrell
Review result: Has Issues

I think there's one issue with this draft that'd be well
worth discussion and/or fixing:

- p12: Why does the cuid need to be so static? I would
have thought that an identifier that can change more
often than a key pair would have been better, esp if this
could be used in a CPE. (Creating a new long-lived
identifier for a CPE seems like a bad plan if it's not
really needed.) For example, one could use both the SPKI
and a timestamp as input for a recommended way to generate
a cuid and that should be as unique, but much more easily
changed.  That could also mitigate the possible TLS1.2
client-cert snooping issue mentioned on p90.

nits:

- (Not really a nit, but probably too much to ask, so...)
The protocol here seems very complex. Has anyone 
tried to prove anything about the state machine, e.g.
that's it's safe in some senses? It'd be fair to say that
that is a good task to do after the initial RFC is
published in this case, I guess.  OTOH, could be some of
the theorem-proving tools used in the development of
TLS1.3 could be useful here. (And those tools usually
do turn up some issues worth fixing - I'd bet a beer they 
would in this case:-)

- p18: "Only single-valued 'cdid' are defined in this
document." That confused me given the text 3 paras
before about multiple cdid values. Maybe clarifying that
some could be useful?

- p77 has a few lowercase "should" and "must" statements.
Not sure if that's on purpose or by accident.

- p90: Is the mention of TCP-AO there for real? I'd be
happy it it were but if it's merely aspirational and you
don't think it'll be used, it'd be better to not pretend
it might get used.

- Couldn't a bad actor in control of an authorised DOTS
client colluding with the controller of a DDoS attack
use this to probe the system to see how their attack is
going and change the attack to be more effective?  I don't
think any protocol change could help there, but perhaps
you could give some guidance to implementers to try catch
such cases (e.g., if the probing DOTS client's local n/w
doesn't actually appear to be under attack).

---

From: <[email-masked]>
Date: Thu, 14 Mar 2019 16:17:10 +0000

Hi Stephen, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 14 mars 2019 16:34
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Secdir last call review of draft-ietf-dots-signal-channel-30
> 

[Med] cuid is used for avoidance detection but also as a stable key to identify resources at the server side. Any change of the cuid will lead to a failure in accessing the resources.
Furthermore, this identifier is used to "glue" the signal and data channels.  

The spec does not forbid the clients to change its cuid, but to do so, the client will need to manage state migration. 

> do turn up some issues worth fixing - I'd bet a beer they

[Med] The specification was edited following an incremental approach in which new pieces are validated through at least two interoperable implementations. We hope that more feedback will be received after the initial RFC.   

> before about multiple cdid values. Maybe clarifying that

[Med] What is meant here is the case where multiple GWs are involved in the path; each inserts a cdid value. 

Will clarify the text.   

> Not sure if that's on purpose or by accident.

[Med] I confirm it was on purpose. These are not new requirements (see Section 7.2).  

> don't think it'll be used, it'd be better to not pretend

[Med] We are providing an example of how the issue can be solved. That is fine, IMO.

> going and change the attack to be more effective?

[Med] The client will only see the reports for attacks it detected and signaled. That bad actor won't signal the attack in the first place!

  I don't

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Mar 2019 16:40:16 +0000

Hiya,

Just on two bits below...

I'm happy to chat more but also fine that you and the ADs can
sort this out according to however the ADs see this.

On 14/03/2019 16:17, [email-masked] wrote:

>> I think there's one issue with this draft that'd be well worth
>> discussion and/or fixing:
>> 
>> - p12: Why does the cuid need to be so static? I would have thought
>> that an identifier that can change more often than a key pair would
>> have been better, esp if this could be used in a CPE. (Creating a
>> new long-lived identifier for a CPE seems like a bad plan if it's
>> not really needed.) For example, one could use both the SPKI and a
>> timestamp as input for a recommended way to generate a cuid and
>> that should be as unique, but much more easily changed.  That could
>> also mitigate the possible TLS1.2 client-cert snooping issue
>> mentioned on p90.
> 
> [Med] cuid is used for avoidance detection but also as a stable key
> to identify resources at the server side. Any change of the cuid will
> lead to a failure in accessing the resources. Furthermore, this
> identifier is used to "glue" the signal and data channels.
> 
> The spec does not forbid the clients to change its cuid, but to do
> so, the client will need to manage state migration.

Yep, I get that. But the current alg that's described for
cuid calculation has the effect of creating an identifier
with the same lifetime as a key pair. Assuming keys are
harder to change than cuids it seems better to encourage
clients to not make such a tight linkage between cuid and
keys, esp. if the client is on a CPE. (And it avoids the
TLS1.2 snooping issue as noted.)

I'd encourage you to consider maybe saying some more about
how clients can change cuid, but even if not, to provide
a cuid calculation example that doesn't link only to the
key pair.

>> - Couldn't a bad actor in control of an authorised DOTS client
>> colluding with the controller of a DDoS attack use this to probe
>> the system to see how their attack is going and change the attack
>> to be more effective?
> 
> [Med] The client will only see the reports for attacks it detected
> and signaled. That bad actor won't signal the attack in the first
> place!

Perhaps I wasn't clear. ISTM that all clients can get information
about how an attack is being seen at other clients, isn't that
right? (The spec does talk about that IIRC.) The colluding client
might or might not be under attack but non-compromised clients will
presumably ask for the attack to be mitigated. So the colluding
client could use this protocol to probe and see how well or badly
the DDoS-mitigation infrastructure is handling an ongoing attack.
I'm basically saying that that may be noteworthy as a security
consideration.

Cheers,
S.

> 
> I don't
>> think any protocol change could help there, but perhaps you could
>> give some guidance to implementers to try catch such cases (e.g.,
>> if the probing DOTS client's local n/w doesn't actually appear to
>> be under attack).
>> 
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 15 Mar 2019 04:30:07 +0000

Please see inline 

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, March 14, 2019 9:47 PM
> To: Stephen Farrell <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Stephen,
> 
> > De : Stephen Farrell via Datatracker [mailto:[email-masked]] Envoyé
> > : jeudi 14 mars 2019 16:34 À : [email-masked] Cc :
> > [email-masked]; [email-masked];
> > [email-masked] Objet : Secdir last call review of
> > draft-ietf-dots-signal-channel-30
> >
> > have been better, esp if this could be used in a CPE. (Creating a new
> > long-lived identifier for a CPE seems like a bad plan if it's not
> > really needed.) For example, one could use both the SPKI and a
> > timestamp as input for a recommended way to generate a cuid and that
> > should be as unique, but much more easily changed.  That could also
> > mitigate the possible TLS1.2 client-cert snooping issue mentioned on
> > p90.
> 
> [Med] cuid is used for avoidance detection but also as a stable key to
> identify resources at the server side. Any change of the cuid will lead to a
> failure in accessing the resources.
> The spec does not forbid the clients to change its cuid, but to do so, the
> client will need to manage state migration.
> 
> >
> > nits:
> >
> > - (Not really a nit, but probably too much to ask, so...) The protocol
> > here seems very complex. Has anyone tried to prove anything about the
> > state machine, e.g.
> > that's it's safe in some senses? It'd be fair to say that that is a
> > good task to do after the initial RFC is published in this case, I
> > guess.  OTOH, could be some of the theorem-proving tools used in the
> > development of
> > TLS1.3 could be useful here. (And those tools usually do turn up some
> > issues worth fixing - I'd bet a beer they would in this case:-)
> 
> [Med] The specification was edited following an incremental approach in
> which new pieces are validated through at least two interoperable
> implementations. We hope that more feedback will be received after the
> initial RFC.
> 
> >
> > - p18: "Only single-valued 'cdid' are defined in this document." That
> > confused me given the text 3 paras before about multiple cdid values.
> > Maybe clarifying that some could be useful?
> 

'cdid' is only inserted by the server-domain DOTS gateway. Figure 8 needs to be corrected, 'cuid' is missing in the Figure.

Cheers,
-Tiru

> > - p90: Is the mention of TCP-AO there for real? I'd be happy it it
> > were but if it's merely aspirational and you don't think it'll be
> > used, it'd be better to not pretend it might get used.
> >
> 
> > colluding with the controller of a DDoS attack use this to probe the
> > system to see how their attack is going and change the attack to be
> > more effective?
> 
> [Med] The client will only see the reports for attacks it detected and signaled.
> That bad actor won't signal the attack in the first place!
> 
>   I don't
> > think any protocol change could help there, but perhaps you could give
> > some guidance to implementers to try catch such cases (e.g., if the
> > probing DOTS client's local n/w doesn't actually appear to be under
> > attack).
> >
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 15 Mar 2019 06:47:27 +0000

Hi Stephen, 

Please see inline. 

Cheers,
Med

> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : jeudi 14 mars 2019 17:40
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : Re: Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> 
> Hiya,
> 

[Med] The text already cites RFC 4122 as an alternate scheme. 

Will consider how to enhance the text. Thanks.

> right? 

[Med] No. A client can only get information that is bound to it. 

(The spec does talk about that IIRC.) The colluding client

---

From: <[email-masked]>
Date: Fri, 15 Mar 2019 07:39:22 +0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : vendredi 15 mars 2019 05:30
> À : BOUCADAIR Mohamed TGI/OLN; Stephen Farrell; [email-masked]
> Objet : RE: Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> Please see inline
> 
> 'cdid' is only inserted by the server-domain DOTS gateway.

[Med] I added this NEW text to clarify the comment from Stephen:

OLD:
      Only single-valued 'cdid' are defined in this document.  

NEW:
      Only single-valued 'cdid' are defined in this document.  That is,
      only the first server-domain DOTS gateway can insert a 'cdid'
      value.  This specification does not allow multiple server-domain
      DOTS gateways, whenever involved in the path, to insert a 'cdid'
      value for each.

 Figure 8 needs to
> be corrected, 'cuid' is missing in the Figure.

[Med] Figure 8 is correct.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 15 Mar 2019 08:35:13 +0000

> From: [email-masked] <[email-masked]>
> Sent: Friday, March 15, 2019 1:09 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Stephen Farrell <[email-masked]>; [email-masked]
> Subject: RE: Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> open attachments unless you recognize the sender and know the content is safe.
> 
> Hi Tiru,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed TGI/OLN; Stephen Farrell; [email-masked] Cc :
> > [email-masked] Objet : RE: Secdir last call review of
> > > Subject: Re: [Dots] Secdir last call review of
> > > draft-ietf-dots-signal-
> > channel-30
> > >
> > > This email originated from outside of the organization. Do not click
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Stephen,
> > >
> > > > Envoyé
> > > > - p12: Why does the cuid need to be so static? I would have
> > > > thought that an identifier that can change more often than a key
> > > > pair would have been better, esp if this could be used in a CPE.
> > > > (Creating a new long-lived identifier for a CPE seems like a bad
> > > > plan if it's not really needed.) For example, one could use both
> > > > the SPKI and a timestamp as input for a recommended way to
> > > > generate a cuid and that should be as unique, but much more easily
> > > > changed.  That could also mitigate the possible TLS1.2 client-cert
> > > > snooping issue mentioned on p90.
> > >
> > > to identify resources at the server side. Any change of the cuid
> > > will lead to
> > a
> > > > - (Not really a nit, but probably too much to ask, so...) The
> > > > protocol here seems very complex. Has anyone tried to prove
> > > > anything about the state machine, e.g.
> > > > that's it's safe in some senses? It'd be fair to say that that is
> > > > a good task to do after the initial RFC is published in this case,
> > > > I guess.  OTOH, could be some of the theorem-proving tools used in
> > > > the development of
> > > > TLS1.3 could be useful here. (And those tools usually do turn up
> > > > some issues worth fixing - I'd bet a beer they would in this
> > > > case:-)
> > >
> > > [Med] The specification was edited following an incremental approach
> > > in which new pieces are validated through at least two interoperable
> > > implementations. We hope that more feedback will be received after
> > > the initial RFC.
> > >
> > > >
> > > > - p18: "Only single-valued 'cdid' are defined in this document."
> > > > That confused me given the text 3 paras before about multiple cdid values.

Replace "only the first server-domain" with "only the first on-path server-domain"

>       DOTS gateways, whenever involved in the path, to insert a 'cdid'

Looks good. 

> [Med] Figure 8 is correct.

Yes.

Cheers,
-Tiru

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Mar 2019 10:19:46 +0000

Hiya,

On 15/03/2019 06:47, [email-masked] wrote:
>> ISTM that all clients can get information
Where does the spec say that? I don't recall the term "bound"
used that way but may have missed it.

And it still seems a bit hard to enforce. If two clients (one
ok, one zombied) ask the same server/network how many packets
targetted at 10.0.0/24 were dropped won't they get the same
answer? (Assuming both clients are within that /24.)

Thanks,
S.

---

From: <[email-masked]>
Date: Fri, 15 Mar 2019 10:45:12 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 15 mars 2019 11:20

[Med] The specification says: 

   If a DOTS client is entitled to solicit the DOTS service, the DOTS
   server enables mitigation on behalf of the DOTS client by
   communicating the DOTS client's request to a mitigator (which may be
   colocated with the DOTS server) and relaying the feedback of the
   thus-selected mitigator to the requesting DOTS client.
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And 

   'cuid' is a mandatory Uri-Path parameter for GET requests.

> answer? (Assuming both clients are within that /24.)

[Med] Attack status information is bound to a DOTS client as shown in the YANG tree module: 

           +--:(mitigation-scope)
           |  +--rw scope* [cuid mid]
           |     +--rw cdid?                   string
           |     +--rw cuid                    string
           |     +--rw mid                     uint32
                ...
           |     +--ro status?                 iana-signal:status
                ...
           |     +--ro bytes-dropped?          yang:zero-based-counter64
           |     +--ro bps-dropped?            yang:zero-based-counter64
           |     +--ro pkts-dropped?           yang:zero-based-counter64
           |     +--ro pps-dropped?            yang:zero-based-counter64
           |     +--rw attack-status?          iana-signal:attack-status 

* If client 1 asked for mitigation for 10.0.0/24, then only that client can access to attack status information. 
* If another client 2 asks for mitigation for the same prefix, the server applies a conflict handling procedure and decides which request to maintain as active. Only one mitigation for a given scope can be maintained. Only that selected client can access to the attack status information.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 15 Mar 2019 10:56:13 +0000

Hi Med,

Stephen is referring to an attack where a compromised DOTS client initiates mitigation request for a target resource that is attacked and learns the mitigation efficacy of the DOTS server, informs the mitigation efficacy to DDoS attacker to change the DDoS attack strategy.  

We can add the following lines to address his comment:

A compromised DOTS client can collude with a DDoS attacker to send mitigation request for a target resource, learns the mitigation efficacy from the DOTS server, and conveys the efficacy to the DDoS attacker to learn the mitigation capabilities of the DDoS mitigation and to possibly change the DDoS attack strategy. This attack can be prevented by auditing the behavior of DOTS clients and authorizing the DOTS client to request mitigation for specific target resources.

Cheers,
-Tiru

> Sent: Friday, March 15, 2019 4:15 PM
> > À : BOUCADAIR Mohamed TGI/OLN; [email-masked] Cc :
> > [email-masked] Objet : Re: Secdir last call review of
> > >> ISTM that all clients can get information about how an attack is
> > >> being seen at other clients, isn't that right?
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And
> 
> > And it still seems a bit hard to enforce. If two clients (one ok, one
> > zombied) ask the same server/network how many packets targetted at
> > 10.0.0/24 were dropped won't they get the same answer? (Assuming both
> > clients are within that /24.)
> 
> * If another client 2 asks for mitigation for the same prefix, the server applies a
> conflict handling procedure and decides which request to maintain as active.
> Only one mitigation for a given scope can be maintained. Only that selected
> client can access to the attack status information.
>

---

From: <[email-masked]>
Date: Fri, 15 Mar 2019 12:26:52 +0000

Tiru, 

I'm not sure if this is the case Stephen is referring to, but this falls under the generic considerations: 

   High-level DOTS security considerations are documented in
   [I-D.ietf-dots-requirements] and [I-D.ietf-dots-architecture].

And then I-D.ietf-dots-requirements: 

   To detect compromised DOTS agents, DOTS operators should carefully
   monitor and audit DOTS agents to detect misbehavior and to deter
   misuse, while employing current secure network communications best
   practices to reduce attack surface.

Still, a good strategy for an attack to succeed is to not signal the attack! 

Cheers,
Med

> Envoyé : vendredi 15 mars 2019 11:56
> Stephen is referring to an attack where a compromised DOTS client initiates
> mitigation request for a target resource that is attacked and learns the
> mitigation efficacy of the DOTS server, informs the mitigation efficacy to
> DDoS attacker to change the DDoS attack strategy.
> 
> A compromised DOTS client can collude with a DDoS attacker to send mitigation
> request for a target resource, learns the mitigation efficacy from the DOTS
> server, and conveys the efficacy to the DDoS attacker to learn the mitigation
> capabilities of the DDoS mitigation and to possibly change the DDoS attack
> strategy. This attack can be prevented by auditing the behavior of DOTS
> clients and authorizing the DOTS client to request mitigation for specific
> target resources.
> 
> Cheers,
> -Tiru
> 
> > * If client 1 asked for mitigation for 10.0.0/24, then only that client can
> access
> > to attack status information.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Mar 2019 09:21:32 -0400

Konda, Tirumaleswar Reddy <[email-masked]> wrote:
    > Stephen is referring to an attack where a compromised DOTS client
    > initiates mitigation request for a target resource that is attacked and
    > learns the mitigation efficacy of the DOTS server, informs the
    > mitigation efficacy to DDoS attacker to change the DDoS attack
    > strategy.

Is there a word for an an infantry troup who goes behind enemy lines in order
to communicate how will the artilery is?  I guess a modern form is these
laser targetted missiles, where the target is "painted".

I don't know if there are words for this kind of thing, but this would seem
to describe the situation.

    > A compromised DOTS client can collude with a DDoS attacker to send
    > mitigation request for a target resource, learns the mitigation
    > efficacy from the DOTS server, and conveys the efficacy to the DDoS
    > attacker to learn the mitigation capabilities of the DDoS mitigation
    > and to possibly change the DDoS attack strategy. This attack can be
    > prevented by auditing the behavior of DOTS clients and authorizing the
    > DOTS client to request mitigation for specific target resources.

If a resource is already under attack, there are already mitigation requests
for that target, can a compromised DOTS client leaern anything by requesting
mitigation on the same target?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 15 Mar 2019 14:00:54 +0000

> From: Michael Richardson <[email-masked]>
> Sent: Friday, March 15, 2019 6:52 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; Stephen Farrell
> <[email-masked]>; [email-masked]; draft-ietf-dots-signal-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> 
> to communicate how will the artilery is?  I guess a modern form is these laser
> targetted missiles, where the target is "painted".
> 
> I don't know if there are words for this kind of thing, but this would seem to
> describe the situation.
> 
> If a resource is already under attack, there are already mitigation requests for
> that target, can a compromised DOTS client leaern anything by requesting
> mitigation on the same target ?

I meant the scenario where the compromised DOTS client initiates the mitigation request before the legitimate DOTS client sends the mitigation request to the DOTS server. DOTS clients are typically trusted devices like Firewalls/IPS, DDoS mitigators/detectors. In future, application servers and endpoints can act as DOTS clients.

-Tiru

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-

---

From: <[email-masked]>
Date: Fri, 29 Mar 2019 05:52:28 +0000

Hi Stephen, 

FWIW, a new version that integrates your comments is available online. The diff can be tracked at:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-31.txt 

Please let me know if you have further comments. 

Thank you.

Cheers,
Med