Subject: [Dots] TR: New Version Notification for draft-boucadair-dots-dhcp-00.txt

From: <[email-masked]>
Date: Thu, 6 Apr 2017 12:42:50 +0000

Dear all, 

Given that:
* means to provision a DOTS client with the address(es) of its DOTS server are needed,
* many of the use cases discussed in draft-ietf-dots-use-cases rely upon a CPE, 
* reserving anycast-addresses for DOTS may be not be justified (see the problems discussed in Section 3.2.4.1 of draft-ietf-dots-architecture)

Leveraging on existing provisioning tools is much more pragmatic. This draft specifies DHCP options to discover a list of IP addresses of a DOTS server. 

Comments, questions and suggestions are more than welcome.

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : jeudi 6 avril 2017 14:25
> À : BOUCADAIR Mohamed IMT/OLN
> Objet : New Version Notification for draft-boucadair-dots-dhcp-00.txt
> 
> 
> A new version of I-D, draft-boucadair-dots-dhcp-00.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> 
> Name:		draft-boucadair-dots-dhcp
> Revision:	00
> Title:		DHCP Options for DDoS Open Threat Signaling (DOTS)
> Document date:	2017-04-06
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-boucadair-dots-
> dhcp-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-boucadair-dots-
> dhcp/
> Htmlized:       https://tools.ietf.org/html/draft-boucadair-dots-dhcp-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-boucadair-
> dots-dhcp-00
> 
> 
> Abstract:
>    It may not be possible for a network to determine the cause for an
>    attack, but instead just realize that some resources seem to be under
>    attack.  To fill that gap, DDoS Open Threat Signaling (DOTS) allows a
>    DOTS client to inform a DOTS server that the network is under a
>    potential attack so that appropriate mitigation actions are
>    undertaken.
> 
>    This document specifies DHCP (IPv4 and IPv6) options to configure
>    hosts with DOTS servers.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 7 Apr 2017 07:06:01 +0000

How will the DOTS client authenticate the discovered DOTS server ?
DOTS client need to be provisioned with the domain name of DOTS server for PKIX based authentication. We discussed this problem in detail in TURN server discovery draft (one of the modes of discovery is DHCP in https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-12) and the problem in this case is DOTS client cannot skip DOTS server authentication.

I also don't see a problem with anycast, anycast DOTS server can re-direct the DOTS client to a unicast IP address and the DOTS client need not know if the DOTs server is using anycast or unicast IP address.

-Tiru

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, April 6, 2017 6:13 PM
> To: [email-masked]
> Subject: [Dots] TR: New Version Notification for draft-boucadair-dots-dhcp-
> 00.txt
> 
> Dear all,
> 
> Given that:
> * reserving anycast-addresses for DOTS may be not be justified (see the
> problems discussed in Section 3.2.4.1 of draft-ietf-dots-architecture)
> 
> Leveraging on existing provisioning tools is much more pragmatic. This draft
> specifies DHCP options to discover a list of IP addresses of a DOTS server.
> 
> > De : [email-masked] [mailto:[email-masked]] Envoyé
> > : jeudi 6 avril 2017 14:25 À : BOUCADAIR Mohamed IMT/OLN Objet : New
> > Version Notification for draft-boucadair-dots-dhcp-00.txt
> >
> >
> > A new version of I-D, draft-boucadair-dots-dhcp-00.txt has been
> > successfully submitted by Mohamed Boucadair and posted to the IETF
> > repository.
> >
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > The IETF Secretariat
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 7 Apr 2017 08:09:49 +0000

Hi Tiru, 

Please see inline.

Cheers,
Med

> De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Envoyé : vendredi 7 avril 2017 09:06
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: New Version Notification for draft-boucadair-dots-dhcp-00.txt
> 

[Med] This is exactly the same situation as discovering DNS servers using DHCP through a trusted network (illegitimate DNS servers may be used to redirect traffic to illegitimate servers). As a reminder, the DHCP discovery case targets DOTS cases where CPEs are involved.  

> DOTS client need to be provisioned with the domain name of DOTS server for
> PKIX based authentication. We discussed this problem in detail in TURN
> server discovery draft (one of the modes of discovery is DHCP in
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-12) and
> the problem in this case is DOTS client cannot skip DOTS server
> authentication.

[Med] OK, but still this is deployment-specific IMHO. DOTS deployments relying upon a CPE may leverage on existing authorization tools deployed at that network. I agree this is more problematic for the cloud case. When DOTS agents are under the same control entity (e.g., the orchestration scenario discussed in the use-cases draft), some constraints may be relaxed too.

> 
> I also don't see a problem with anycast, anycast DOTS server can re-direct
> the DOTS client to a unicast IP address and the DOTS client need not know
> if the DOTs server is using anycast or unicast IP address.

[Med] The use of anycast may be convenient for some deployments, but it may not be for others. The DOTS architecture draft is clear about this 

   "The DOTS architecture does not assume the availability of anycast
   within a DOTS deployment, but neither does the architecture exclude
   it. "

The DHCP option can be used to provision an anycast address, if a deployment requires so.

Deployments that requires a control on the load of DOTS servers would prefer to provision explicit unicast addresses to DOTS clients. 

> > * means to provision a DOTS client with the address(es) of its DOTS
> server are
> > needed,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 7 Apr 2017 13:13:47 +0000

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, April 7, 2017 1:40 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; [email-masked]
> Subject: RE: New Version Notification for draft-boucadair-dots-dhcp-00.txt
> 
> Hi Tiru,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] Envoyé :
> > vendredi 7 avril 2017 09:06 À : BOUCADAIR Mohamed IMT/OLN;
> > [email-masked] Objet : RE: New Version Notification for
> > draft-boucadair-dots-dhcp-00.txt
> >
> [Med] This is exactly the same situation as discovering DNS servers using DHCP
> through a trusted network (illegitimate DNS servers may be used to redirect
> traffic to illegitimate servers). As a reminder, the DHCP discovery case targets
> DOTS cases where CPEs are involved.

The above attack is addressed by the work happening in DPIVE WG, DNS client can authenticate the 
DNS server using DNS over (D)TLS.

> 
> > DOTS client need to be provisioned with the domain name of DOTS server
> > for PKIX based authentication. We discussed this problem in detail in
> > TURN server discovery draft (one of the modes of discovery is DHCP in
> > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-12)
> > and the problem in this case is DOTS client cannot skip DOTS server
> > authentication.
> 
> [Med] OK, but still this is deployment-specific IMHO. 

Mutual authentication b/w the DOTS client and server is mandatory as per the requirements draft.

> DOTS deployments
> relying upon a CPE may leverage on existing authorization tools deployed at
> that network. I agree this is more problematic for the cloud case. When DOTS
> agents are under the same control entity (e.g., the orchestration scenario
> discussed in the use-cases draft), some constraints may be relaxed too.

Inside attacks are possible in an Enterprise network.

> 
> >
> > I also don't see a problem with anycast, anycast DOTS server can
> > re-direct the DOTS client to a unicast IP address and the DOTS client
> > need not know if the DOTs server is using anycast or unicast IP address.
> 
> [Med] The use of anycast may be convenient for some deployments, but it
> may not be for others. The DOTS architecture draft is clear about this
> 
> Deployments that requires a control on the load of DOTS servers would prefer
> to provision explicit unicast addresses to DOTS clients.

DOTS server listening on anycast IP address can re-direct the client to an optimal unicast IP address 
based on load.

-Tiru

> > > Subject: [Dots] TR: New Version Notification for
> > > draft-boucadair-dots-
> > dhcp-
> > > 00.txt
> > >
> > > Dear all,
> > >
> > > Given that:
> > > * many of the use cases discussed in draft-ietf-dots-use-cases rely
> > > upon
> > a CPE,
> > > * reserving anycast-addresses for DOTS may be not be justified (see
> > > the problems discussed in Section 3.2.4.1 of
> > > draft-ietf-dots-architecture)
> > >
> > > Leveraging on existing provisioning tools is much more pragmatic.
> > > This
> > draft
> > > > Envoyé
> > > > : jeudi 6 avril 2017 14:25 À : BOUCADAIR Mohamed IMT/OLN Objet :
> > > > New Version Notification for draft-boucadair-dots-dhcp-00.txt
> > > >
> > > >
> > > >    attack.  To fill that gap, DDoS Open Threat Signaling (DOTS)
> > > > allows
> > a

---

From: Dave Dolson <[email-masked]>
Date: Fri, 7 Apr 2017 20:21:05 +0000

Med,
How do you think dots security should work for clients provisioned via DHCP?
It seems like we are deciding on a (D)TLS model. How would the keys be provisioned?

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, April 6, 2017 8:43 AM
To: [email-masked]
Subject: [Dots] TR: New Version Notification for draft-boucadair-dots-dhcp-00.txt

Dear all, 

Given that:

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 10 Apr 2017 06:02:00 +0000

Hi Tiru, 

Please see inline.

Cheers,
Med

> Envoyé : vendredi 7 avril 2017 15:14

[Med] I'm not sure dprive dealt with trusted DHCP servers and how this trust relationship can be put in place. 

> Mutual authentication b/w the DOTS client and server is mandatory as per

[Med]  Yes, I know. I do think there is a need to reconsider the wording of that requirement to relax it for deployments with trusted DHCP servers to leverage on existing tools to authenticate/authorize DOTS clients. Leveraging on existing tools is motivated by various reasons: 
•	minimize the requirements on the CPE so that it can embed a DOTS client
•	minimize provisioning data on the CPE because that data may be lost due to a system crash (and therefore lead to calls to the hotline). 
•	If credentials to authenticate the DOTS server are provisioned anyway by the provider on the CPE, this biases the DOTS server authentication. Trusting the DOTS server provisioned by the provider + authenticate the DOTS client provides the same protection level.

For deployments that require mutual authentication, the DHCP option can be designed to return a domain name.

> > The DHCP option can be used to provision an anycast address, if a
> deployment
> > requires so.
> >

[Med] Tiru, this one deployment option. The DOTS architecture cannot mandate it. It is up to the entity that offers the DOTS service to decide about its engineering. ACKing the limit of a anycast-based approach as documented in the architecture draft is the right approach. 

> > > > > URL:            https://www.ietf.org/internet-drafts/draft-
> boucadair-
> > > dots-
> > > > > dhcp-00.txt
> > > > > Htmlized:       https://tools.ietf.org/html/draft-boucadair-dots-
> dhcp-
> > > 00

---

From: <[email-masked]>
Date: Mon, 10 Apr 2017 06:37:00 +0000

Hi Dave, 

Please see inline. 

Cheers,
Med

> De : Dave Dolson [mailto:[email-masked]]
> Envoyé : vendredi 7 avril 2017 22:21

[Med] A simple approach is to leverage on security features already supported by CPEs to provide some sensitive services with similar requirements. A typical example is a SIP agent embedded on the CPE. For deployments that require DTLS mutual authentication, the DHCP option can be designed to return an authentication domain name. Of course, this model assumes that DHCP server is trusted. 

> It seems like we are deciding on a (D)TLS model. How would the keys be

[Med] For the CPE-based model I'm interested in, security keys can be provisioning following current practices for similar services and deployments. In such deployments, IP-specific configuration parameters are provided using DHCP while service-specific parameters are passed using channels such as TR-69 and its extensions (see for example, TR-104 for the VoIP case (https://www.broadband-forum.org/technical/download/TR-104_Issue-2.pdf)). 

FWIW, you may refer to https://www.broadband-forum.org/technical/download/TR-181_Issue-2_Amendment-11.pdf (starting from page 133) to see a recent feature that was added (PCP client) and how a PCP server is configured to the CPE. That model assumes that the server can be provisioned by means of DHCP, but other parameters such as filtering rules are may be provisioned via TR-69. 

> Leveraging on existing provisioning tools is much more pragmatic. This
> draft specifies DHCP options to discover a list of IP addresses of a DOTS
> server.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 10 Apr 2017 06:55:05 +0000

Hi Med,

Please see inline

> Sent: Monday, April 10, 2017 11:32 AM
> > vendredi 7 avril 2017 15:14 À : BOUCADAIR Mohamed IMT/OLN;
> > > traffic to illegitimate servers). As a reminder, the DHCP discovery
> > > case
> > targets
> > The above attack is addressed by the work happening in DPIVE WG, DNS
> > client can authenticate the DNS server using DNS over (D)TLS.
> 

Please see https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-08 

> 
> >
> > >
> > > > DOTS client need to be provisioned with the domain name of DOTS
> > > > server for PKIX based authentication. We discussed this problem in
> > > > detail in TURN server discovery draft (one of the modes of
> > > > discovery is DHCP in
> > > > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-
> > > > 12) and the problem in this case is DOTS client cannot skip DOTS
> > > > server authentication.
> > >
> [Med]  Yes, I know. I do think there is a need to reconsider the wording of that
> requirement to relax it for deployments with trusted DHCP servers to leverage
> on existing tools to authenticate/authorize DOTS clients. Leveraging on
> existing tools is motivated by various reasons:

It's easy to implement a DOTS client on a CPE with (D)TLS (just like a IOT gateway, SIP proxy, media gateway using DTLS-SRTP etc.). 

> •	minimize provisioning data on the CPE because that data may be lost
> due to a system crash (and therefore lead to calls to the hotline).

The Provisioning data for mutual authentication can be stored on flash to survive crash 
and does not consume much space.

> •	If credentials to authenticate the DOTS server are provisioned anyway
> by the provider on the CPE, this biases the DOTS server authentication.
> Trusting the DOTS server provisioned by the provider + authenticate the DOTS
> client provides the same protection level.

How are the attacks handled where attacker impersonates DOTS client or DOTS server ? 

> designed to return a domain name.

I still don't see the need for the new DHCP option, OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN can be used to get the domain name and then use DNS service discovery as discussed in Section 3.1.2 of DOTS architecture draft. 

-Tiru

> 
> >
> > > DOTS deployments
> > > relying upon a CPE may leverage on existing authorization tools
> > > deployed
> > at
> > > that network. I agree this is more problematic for the cloud case.
> > > When
> > DOTS
> > > > re-direct the DOTS client to a unicast IP address and the DOTS
> > > > client need not know if the DOTs server is using anycast or
> > > > unicast IP
> > address.
> > >
> > > [Med] The use of anycast may be convenient for some deployments, but
> > > it may not be for others. The DOTS architecture draft is clear about
> > > this
> > >
> > > Deployments that requires a control on the load of DOTS servers
> > > would
> > prefer
> > DOTS server listening on anycast IP address can re-direct the client
> > to an optimal unicast IP address based on load.
> >
> 
> [Med] Tiru, this one deployment option. The DOTS architecture cannot
> mandate it. It is up to the entity that offers the DOTS service to decide about
> its engineering. ACKing the limit of a anycast-based approach as documented
> in the architecture draft is the right approach.
> > -Tiru
> >
> > >
> > >
> > > >
> > > > -Tiru
> > > >

---

From: <[email-masked]>
Date: Mon, 10 Apr 2017 07:06:51 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 10 avril 2017 08:55
> Envoyé :
> > [Med] I'm not sure dprive dealt with trusted DHCP servers and how this
> trust
> > relationship can be put in place.
> 

[Med] This document confirms what I stated earlier:

" However when using a Strict profile the DHCP
   servers used as sources of authentication domain names MUST be
                                                          ^^^^^^^^
   considered secure and trustworthy.  This document does not attempt to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   describe secured and trusted relationships to DHCP servers."
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > > > > 12) and the problem in this case is DOTS client cannot skip DOTS
SKIP
> > For deployments that require mutual authentication, the DHCP option can
> be
> > designed to return a domain name.
> 
> I still don't see the need for the new DHCP option,
> OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN can be used to get the
> domain name and then use DNS service discovery as discussed in Section
> 3.1.2 of DOTS architecture draft.

[Med] Your proposed approach does not allow for deterministic association of DOTS clients-->DOTS server. Further, it does make deployment assumptions. I don't think it is up to us to make this choice.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 10 Apr 2017 07:18:53 +0000

> Sent: Monday, April 10, 2017 12:37 PM
> > lundi 10 avril 2017 08:55 À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> > > > > Subject: RE: New Version Notification for
> > > > > [Med] This is exactly the same situation as discovering DNS
> > > > > servers
> > > > using DHCP
> > > > > through a trusted network (illegitimate DNS servers may be used
> > > > > to
> > > > redirect
> > > > > traffic to illegitimate servers). As a reminder, the DHCP
> > > > > discovery case
> > > > targets
> > > > The above attack is addressed by the work happening in DPIVE WG,
> > > > DNS client can authenticate the DNS server using DNS over (D)TLS.
> > >

There are no deployed standard mechanisms for the client know if the DHCP server is authentic, hence it is relying other 
modes for authenticating the DNS server.

> 
> > >
> > > >
> > > > >
> > > > > > DOTS client need to be provisioned with the domain name of
> > > > > > DOTS server for PKIX based authentication. We discussed this
> > > > > > problem in detail in TURN server discovery draft (one of the
> > > > > > modes of discovery is DHCP in
> > > > > > 12) and the problem in this case is DOTS client cannot skip
> > > > > > DOTS server authentication.
> > > > >
> SKIP
> >
> > OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN can be
> used to get
> > the domain name and then use DNS service discovery as discussed in
> > Section
> [Med] Your proposed approach does not allow for deterministic association of
> DOTS clients-->DOTS server. Further, it does make deployment assumptions. I
> don't think it is up to us to make this choice.

Skipping mutual authentication is also a deployment assumption. 

-Tiru

---

From: <[email-masked]>
Date: Mon, 10 Apr 2017 08:03:33 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 10 avril 2017 09:19
> There are no deployed standard mechanisms for the client know if the DHCP
> server is authentic, hence it is relying other

[Med] I think we are in agreement here. 

> Skipping mutual authentication is also a deployment assumption.

[Med] Skipping mutual authentication may be indeed a deployment option. The DHCP design allows for it...but it does not prevent it. For example, when a DOTS domain name is provided, that domain name can be used for RKIX authentication but also, and more important, it allows to find the appropriate DOTS server to contact.