From nobody Fri Dec 1 06:17:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D51128D64 for ; Fri, 1 Dec 2017 06:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKOzAsalvDxe for ; Fri, 1 Dec 2017 06:17:14 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3479127078 for ; Fri, 1 Dec 2017 06:17:13 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eKm7q-000076-GW; Fri, 01 Dec 2017 14:17:10 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 1 Dec 2017 14:17:11 -0000 Message-ID: <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019E_01D36AAF.1425F7D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99QHmvtxLArQ3BpMBrkCf6AG8EcvIAftFitMBk8OATQDr9ZOXAY4zRQIBQLfdVgD+ExMRAi0RRmsCNnHIagKk01sxAZIGIAIBo54sZaGOI0Gw Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:17:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_019E_01D36AAF.1425F7D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 So would we therefore be looking at =20 module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string =20 Where conflict-scope =91hints=92 at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition = =96 should this also be a conflict-scope definition? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 If required =93additional-status=94 can be added in future = specifications; As you already know, DOTS protocol is extensible to define new standard and vendor-specific parameters. @Jon =96 Yes, ietf-dots-signal needs to be modified to include the = mitigation status parameters.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 This also looks good to me in principal. =20 I do not think we need the =93additional-status=94 layer =96 why not = just go straight to =93conflict-information=94? [Med] This is to leave it extensible if we need in the future to supply = more information for other purposes than conflicts. Does it make sense? =20 I would like to see added =93conflict-reason=94 with some defined = conflict codes under =93conflict-information=94. =20 However, none of this status (including bytes-dropped etc.) is defined = in the yang module: ietf-dots-signal as ro entities. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Looks good to me. =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru,=20 =20 With the =93additional-status=94 parameter, and given the current values = defined in Table 2, I don=92t see which status code to return when = =93additional-status=94 is set to =933 | DOTS Server has detected conflicting mitigation = requests from different DOTS clients. All conflicting mitigation requests are = inactive=94. I=92m afraid new status codes should be defined for this to work (e.g., = =93X: Attack mitigation is withdrawn=94, =93Y: Attack mitigation is = rejected=94).=20 =20 Note that in both approaches, we will need to supply additional = information to characterize the conflict (conflict-information). This information = should be returned to all clients. =20 So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including =91additional-status=92. Define = =91conflict-information=92 under that parent; =91conflict-information=92 can include the following sub-parameters: o conflict-status: three codes=20 =A7 1 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently inactive = until the conflicts are resolved. Another mitigation request is active. =A7 2 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently active.=20 =A7 3 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are = inactive. o conflict-scope: same structure as =93scope=94 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 The proposal works for me, is the plan to add 7, 8 and 9 status or add a = new =93additional-status=94 parameter ? =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru,=20 =20 I agree with you that discarding all conflicting requests may not be = helpful in some cases. In the same way that someone can argue that selecting = only one request among conflicting ones may not be useful because the server picked the wrong one. =20 =20 I do prefer to leave this to implementation/deployment as a policy to be supplied. That policy will instruct the dots server about the behavior = to follow based one specific information that is available for a given deployment: =20 =B7 Pick one and deactivate all the others based on some criteria =B7 Activate all of them =B7 De-activate all of them=20 =20 Cheers, Med=20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-built DDoS detection capability. The web server may not have as much = visibility into the extent of the DDoS attack as the DDoS Detector (or IDMS) and = there will be conflicting mitigation requests from different DOTS clients, discarding all the mitigation requests from different clients will make = the mechanism not useful. =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Tiru,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification =20 Within a administrative domain, there won=92t be many different DOTS = clients raising conflicting mitigation requests for the same target, the = conflict may arise between a DDoS Detector (or a on premise DDoS mitigation = system) acting as DOTS clients and a web server with in-built DDoS detection capability. =20 [Med] I don=92t think that we can speculate about the nature of the = conflicts that may happen. Misconfigured and corrupted software instances may = happen.=20 =20 Under what conditions does the DOTS server return =93DOTS Server has = detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are inactive.=94 ? [Med] A dots server can be typically instructed by a policy to discard conflicting requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before solicited the server. The signal-channel does not need to call for a favorite action when conflicts; that is implementation- and deployment-specific. =20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 In principal I accept the concept of your 7, 8 & 9 status which in = effect are part of the mitigation state as in a state diagram. However, having issued a =938=94 status, this then needs to transition to another state = which reflects what is actually happening =96 e.g. =932=94. =20 The actual state could immediately be sent following the reporting of = =938=94 (if Observe active), else it would need to wait until the next status = GET. It is possible that the =938=94 message gets lost, so relying on = receiving the =938=94 could be dangerous. =20 With a =939=94 response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? =20 What is critical is that=20 DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. =20 I also do not want to lose sight of=20 The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request.=94 This potentially can be conveyed in the 4.09 message, or could be a new mitigation status parameter such as "additional-info" with an = appropriate text value. It could be that =93status=94 stays with =931=94 through = =936=94, and (possibly optional) =93additional-status=94 has=20 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 3 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. And =93additional-info=94 reports on what the nature and scope of the = conflict is. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, all, =20 Thank you for sharing your thoughts on this. =20 I tend to allow for both 4.09 code and new status values in the spec.=20 =20 I see that you proposed this new value:=20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =3D=3D =20 Please note that a server may be instructed to adopt a more strict = behavior by deactivating all conflicting requests. Further, all DOTS clients = which issued conflicting requests should be notified, not only the one for = which a request is de-activated. As such, I=92m afraid we will need more values, = e.g., =20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 9 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. =3D=3D =20 For example: * If the server decides to activate only one request, then 7 will be = sent to all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.=20 * If the server decides to deactivate all requests, then 9 will be sent = to all clients. =20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru, =20 If Client-A has invoked a mitigation, then Client-B requests a = conflicting mitigation, if the DOTS server is only allowing the first mitigation = request to be the valid one, then the DOTS server could send back a 4.09 to Client-B. =20 However, if the DOTS server is allowed to choose the best mitigation request, decides it is Client-B, there is no simple way of sending an unsolicited 4.09 to client-A. Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has been de-selected because of a mitigation request conflict. =20 It is also possible that a mitigation state is status 1 (parameter value = =96 Table 2)) and needs to transition to another state =96 at which point = the conflict is found - possibly by the DOTS mitigator - which then needs to = be relayed back through the DOTS server. =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, =20 What is the problem if the DOTS server returns 4.09 (conflict) error response for the conflicting mitigation request from Client-A ? The above error code is already defined = https://tools.ietf.org/html/rfc8132.=20 =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 See inline =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification =20 Hi all,=20 =20 As discussed during the last IETF meeting, we are seeking for feedback = from the WG about how to address this requirement: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D =20 For example, would it be OK if we leave implementation-specific the = criteria upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the procedure to = notify clients when a conflict is detected?=20 Jon> I agree that how this is done is implementation specific. However there is a scenario where Client-A initiates a mitigation requests which = is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the =93more=94 valid mitigation request = and effectively de-activates Client-A=92s request. Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the mitigation. A suggestion would be=20 =20 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =20 Jon> The DOTS client can then elect to leave in the mitigation request = (and even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back = (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting = request and closes down the new PUT request unless we come up with a specific = error code so the DOTS client can understand why the request is getting = errored. =20 =20 Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, = but draft-ietf-dots-signal defines how to inform clients about which action = was enforced by the server?=20 =20 Jon> Again, I think that this would be implementation specific. The suggested Table 2: entry above would cover this as well. The DOTS = client just needs to know it has been de-selected / discarded =96 I don=92t = think the DOTS client needs to know how / why the DOTS server chose that = particular DOTS client. =20 Cheers, Med=20 ------=_NextPart_000_019E_01D36AAF.1425F7D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

So would we therefore be = looking at

 

=A0=A0 module: = ietf-dots-signal

=A0=A0=A0=A0=A0=A0 +--rw = mitigation-scope

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = client-identifier*=A0=A0 binary

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw scope* = [mitigation-id]

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = mitigation-id=A0=A0=A0=A0=A0=A0=A0 int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-ip*=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = inet:ip-address

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-prefix*=A0=A0=A0=A0=A0=A0 inet:ip-prefix

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-port-range* [lower-port upper-port]

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--rw = lower-port=A0=A0=A0 inet:port-number

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--rw = upper-port?=A0=A0 inet:port-number

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-protocol*=A0=A0=A0=A0 uint8

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-fqdn*=A0=A0=A0=A0=A0=A0=A0=A0 = inet:domain-name

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-uri*=A0=A0=A0=A0=A0=A0=A0=A0=A0 inet:uri

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = alias-name*=A0=A0=A0=A0=A0=A0=A0=A0=A0 string

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = lifetime?=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = mitigation-start?=A0=A0=A0 decimal64

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = status?=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = bytes-dropped?=A0=A0=A0=A0=A0=A0 int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = bps-dropped?=A0=A0=A0=A0 =A0=A0=A0=A0int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = pkts-dropped?=A0=A0=A0=A0=A0=A0=A0 int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = pps-dropped?=A0=A0=A0=A0=A0=A0=A0=A0 int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = conflict-information?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = conflict-status?=A0=A0=A0=A0 int32

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro = conflict-scope?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro target-ip*=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = inet:ip-address

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro target-prefix*=A0=A0=A0=A0=A0=A0 = inet:ip-prefix

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro target-port-range* [lower-port = upper-port]

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= |=A0 +--ro lower-port?=A0=A0 inet:port-number

=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0 +--ro upper-port?=A0=A0 = inet:port-number

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro target-protocol*=A0=A0=A0=A0 uint8

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro target-fqdn*=A0=A0=A0=A0=A0=A0=A0=A0 = inet:domain-name

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro target-uri*=A0=A0=A0=A0=A0=A0=A0=A0=A0 = inet:uri

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--ro alias-name*=A0=A0=A0=A0=A0=A0=A0=A0=A0 string

 

Where conflict-scope = ‘hints’ at what the conflicting item = is?

- What happens when the conflict is caused by a = filter/acl definition – should this also be a conflict-scope = definition?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 30 November 2017 = 11:14
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict = detection and notification

 

Hi = Med,

 

If required = “additional-status” can be added in future specifications; = As you already know, DOTS protocol is extensible to define new standard = and vendor-specific parameters.

@Jon – Yes, ietf-dots-signal = needs to be modified to include the mitigation status parameters. =

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Thursday, November 30, 2017 4:24 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : jeudi 30 novembre 2017 = 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

This also looks good to me in = principal.

 

I do not think we need = the “additional-status” layer – why not just go = straight to “conflict-information”?

[Med] This is to leave it extensible if we need in the = future to supply more information for other purposes than conflicts. = Does it make sense?

 

I would like to see = added “conflict-reason” with some defined conflict codes = under “conflict-information”.

 

However, none of this = status (including bytes-dropped etc.) is defined in the yang module: = ietf-dots-signal as ro entities.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 = 10:42
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Looks good to = me.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Thursday, November 30, 2017 3:56 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

With the “additional-status” parameter, = and given the current values defined in Table 2, I don’t see which = status code to return when “additional-status” is set to = “3 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients.  All conflicting mitigation requests are = inactive”. I’m afraid new status codes should be defined for = this to work (e.g., “X: Attack mitigation is withdrawn”, = “Y: Attack mitigation is rejected”). =

 

Note that in both approaches, we will need to supply = additional information to characterize the conflict = (conflict-information). This information should be returned to all = clients.

 

So, what about considering this = direction?

-   Update = the status table with these NEW codes:

o   7: = Attack mitigation is withdrawn

o   8: = Attack mitigation is rejected

-   Allow = for including ‘additional-status’. Define = ‘conflict-information’ under that parent; = ‘conflict-information’ can include the following = sub-parameters:

o   conflict-status: three codes

=A7  1 | = DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  This mitigation request is currently inactive until = the conflicts are resolved. Another mitigation request is = active.

=A7  2 | = DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  This mitigation request is currently active. =

=A7  3 | = DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are = inactive.

o   conflict-scope: same structure as = “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre = 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon = Shallow; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

The proposal works for = me, is the plan to add 7, 8 and 9 status or add a new = “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Wednesday, November 29, 2017 12:02 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

I agree with you that discarding all conflicting = requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not = be useful because the server picked the wrong one. =   

 

I do prefer to leave this to implementation/deployment = as a policy to be supplied. That policy will instruct the dots server = about the behavior to follow based one specific information that is = available for a given deployment:  

=B7       = Pick one and deactivate all the others based on some = criteria

=B7       = Activate all of them

=B7       = De-activate all of them

 

Cheers,

Med =

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] signal-channel: Conflict detection and = notification

 

Hi = Med,

 

In a deployment scenario with a = DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS = clients and a web server with in-built DDoS detection capability. The = web server may not have as much visibility into the extent of the DDoS = attack as the DDoS Detector (or IDMS) and there will be conflicting = mitigation requests from different DOTS clients, discarding all the = mitigation requests from different clients will make the mechanism not = useful.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Tuesday, November 28, 2017 8:55 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] signal-channel: Conflict detection and = notification

 

Within a = administrative domain, there won’t be many different DOTS clients = raising conflicting mitigation requests for the same target, the = conflict may arise between a DDoS Detector (or a on premise DDoS = mitigation system) acting as DOTS clients and a web server with in-built = DDoS detection capability. 

[Med] I don’t think = that we can speculate about the nature of the conflicts that may happen. = Misconfigured and corrupted software instances may happen. =

 

Under what conditions does the DOTS = server return “DOTS Server has detected conflicting mitigation = requests from different DOTS clients.  All conflicting mitigation = requests are inactive.” ?

[Med] A dots server can be = typically instructed by a policy to discard conflicting requests. The = rationale is that the provider thinks that the clients are misconfigured = and something is needed to be fixed before solicited the server. The = signal-channel does not need to call for a favorite action when = conflicts; that is implementation- and deployment-specific. =  

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, November 28, 2017 7:45 PM
To: = mohamed.boucadair@orange.com= ; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

In principal I accept = the concept of your 7, 8 & 9 status which in effect are part of the = mitigation state as in a state diagram.  However, having issued a = “8” status, this then needs to transition to another state = which reflects what is actually happening – e.g. = “2”.

 

The actual state could = immediately be sent following the reporting of “8” (if = Observe active), else it would need to wait until the next status = GET.  It is possible that the “8” message gets lost, so = relying on receiving the “8” could be = dangerous.

 

With a “9” = response what then is the DOTS client allowed to = do?

- A retry of the original mitigation request is = likely to fail again

- If all the DOTS clients back off, then there = will be no mitigation

- Should there be a random back-off time before = retrying?

 

What is critical is that =

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.

Should not be allowed to = happen.

 

I also do not want to = lose sight of

The notification SHOULD indicate the = nature and scope of the conflict,

for example, the overlapping prefix range = in a conflicting mitigation request.”

This potentially can be = conveyed in the 4.09 message, or could be a new mitigation status = parameter such as "additional-info" with an appropriate text = value.  It could be that “status” stays with = “1” through “6”, and (possibly optional) = “additional-status” has

0 | This DOTS client = mitigation request is being honoured

1 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

2 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  This mitigation = request is currently active.

3 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  All conflicting mitigation requests are = inactive.

And “additional-info” reports on = what the nature and scope of the conflict is.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 28 November 2017 13:29
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Jon, all,

 

Thank you for sharing your thoughts on = this.

 

I tend to allow for both 4.09 code and new status = values in the spec.

 

I see that you proposed this new value: =

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to adopt a = more strict behavior by deactivating all conflicting requests. Further, = all DOTS clients which issued conflicting requests should be notified, = not only the one for which a request is de-activated. As such, I’m = afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

8 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently active. =

9 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  All conflicting = mitigation requests are inactive.

=3D=3D

 

For example:

* If = the server decides to activate only one request, then 7 will be sent to = all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.

* If = the server decides to deactivate all requests, then 9 will be sent to = all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mardi 28 novembre 2017 = 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

If Client-A has invoked = a mitigation, then Client-B requests a conflicting mitigation, if the = DOTS server is only allowing the first mitigation request to be the = valid one, then the DOTS server could send back a 4.09 to = Client-B.

 

However, if the DOTS = server is allowed to choose the best mitigation request, decides it is = Client-B, there is no simple way of sending an unsolicited 4.09 to = client-A.  Hence suggestion for an additional status message which = can be sent to Client-A stating that Client-A has been de-selected = because of a mitigation request conflict.

 

It is also possible that = a mitigation state is status 1 (parameter value – Table 2)) and = needs to transition to another state – at which point the conflict = is found - possibly by the DOTS mitigator - which then needs to be = relayed back through the DOTS server.

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 28 November 2017 11:42
To: = Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = Jon,

 

What is the problem if the DOTS = server returns 4.09 (conflict) error response for the conflicting = mitigation request from Client-A ?

The above error code is already = defined https://tools.ietf.org/html/rfc8132<= /span>. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, November 28, = 2017 4:50 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 24 November 2017 = 14:03
To: dots@ietf.org
Subject: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = all,

 

As = discussed during the last IETF meeting, we are seeking for feedback from = the WG about how to address this requirement:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflict = Detection and Notification: Multiple DOTS = clients

      controlled = by a single administrative entity may send = conflicting

      mitigation = requests for pools of protected resources as a = result

      of = misconfiguration, operator error, or compromised DOTS = clients.

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.  DOTS servers in a = single

      = administrative domain SHALL detect such conflicting requests, = and

      SHALL = notify the DOTS clients in conflict.  The = notification

      SHOULD = indicate the nature and scope of the conflict, for = example,

      the = overlapping prefix range in a conflicting mitigation = request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For = example, would it be OK if we leave implementation-specific the criteria = upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the = procedure to notify clients when a conflict is detected? =

Jon> I agree that how this is done is = implementation specific.  However there is a scenario where = Client-A initiates a mitigation requests which is acted upon, Client-B = does a conflicting mitigation request but the DOTS Server decides that = Client-B is the “more” valid mitigation request and = effectively de-activates Client-A’s request.  Table 2: = draft-ietf-dots-signal-channel-09 therefore needs an additional status = parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the = mitigation.  A suggestion would be

 

7 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

 

Jon> The = DOTS client can then elect to leave in the mitigation request (and even = refresh the PUT to refresh the timeout) or delete = it.

Jon> I do not think it appropriate that an = error message be sent back (e.g. 4.xx) if the DOTS server immediately = decides there is a conflicting request and closes down the new PUT = request unless we come up with a specific error code so the DOTS client = can understand why the request is getting = errored.

 

 

Likewise, would it be OK if the document does not specify which of = the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about = which action was enforced by the server?

 

Jon> = Again, I think that this would be implementation specific.  The = suggested Table 2: entry above would cover this as well.  The DOTS = client just needs to know it has been de-selected / discarded – I = don’t think the DOTS client needs to know how / why the DOTS = server chose that particular DOTS client.

 

Cheers,

Med =

------=_NextPart_000_019E_01D36AAF.1425F7D0-- From nobody Fri Dec 1 06:55:19 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B87126C3D; Fri, 1 Dec 2017 06:55:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151214011764.11941.4294940955342151135@ietfa.amsl.com> Date: Fri, 01 Dec 2017 06:55:17 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:55:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-10.txt Pages : 69 Date : 2017-12-01 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-10 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 1 06:57:44 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56149120725 for ; Fri, 1 Dec 2017 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L09rQqFl4-I for ; Fri, 1 Dec 2017 06:57:41 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A1C120713 for ; Fri, 1 Dec 2017 06:57:41 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 0047CA0B16 for ; Fri, 1 Dec 2017 15:57:40 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id D94D21A0076 for ; Fri, 1 Dec 2017 15:57:39 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Fri, 1 Dec 2017 15:57:39 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-10.txt Thread-Index: AQHTarRqW3O2sv2gQ0Scsgy0PPZuBKMuk78g Date: Fri, 1 Dec 2017 14:57:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A084D71@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151214011764.11941.4294940955342151135@ietfa.amsl.com> In-Reply-To: <151214011764.11941.4294940955342151135@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:57:43 -0000 Hi all,=20 The updated version integrates the comments from Nesredien and some of the = outcome of the conflict discussion.=20 Please double check and share your comments/questions.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 1 d=E9cembre 2017 15:55 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-10.txt > Pages : 69 > Date : 2017-12-01 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-10 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-10 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 1 07:06:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96A9126C3D for ; Fri, 1 Dec 2017 07:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyuBauvZ2XlG for ; Fri, 1 Dec 2017 07:06:24 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A12120713 for ; Fri, 1 Dec 2017 07:06:23 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id A0EF8204BF; Fri, 1 Dec 2017 16:06:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 346C520071; Fri, 1 Dec 2017 16:06:22 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Fri, 1 Dec 2017 16:06:21 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0QHmvtxLArQ3BpMBrkCf6AG8EcvIAftFitMBk8OATQDr9ZOXAY4zRQIBQLfdVgD+ExMRAi0RRmsCNnHIagKk01sxAZIGIAIBo54sZaGOI0GwoldtmSA= Date: Fri, 1 Dec 2017 15:06:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> In-Reply-To: <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A084D91OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:06:28 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A084D91OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A084D91OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

   &= nbsp;  conflict-cause:  Indicates the cause of the conflict. = ; The

   &= nbsp;     following values are defined:

 

   &= nbsp;     1:  Overlapping target prefixes

 

   &= nbsp;     2:  Conflicts with an existing white lis= t

 

Are there any other codes that = can be listed here?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

 

If required “additional-status” can be added in future sp= ecifications; As you already know, DOTS protocol is extensible to define ne= w standard and vendor-specific parameters.

@Jon – Yes, ietf-dots-signal needs to be modified to include th= e mitigation status parameters.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks good to me.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-stat= us” parameter, and given the current values defined in Table 2, I don= ’t see which status code to return when “additional-status̶= 1; is set to “3 | DOTS Server has detected conflicting mitigation reque= sts from different DOTS clients.  All conflicting mitigation requests = are inactive”. I’m afraid new status codes should be defined fo= r this to work (e.g., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, w= e will need to supply additional information to characterize the conflict (= conflict-information). This information should be returned to all clients.

 

So, what about considering this= direction?

-   Update the status table with these NEW codes:

o=    7: Attack mitigation is withdrawn

o=    8: Attack mitigation is rejected

-   Allow for including ‘additional-status= 217;. Define ‘conflict-information’ under that parent; ‘c= onflict-information’ can include the following sub-parameters:

o=    conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently active.

=A7  3 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  All conflicting mitigation= requests are inactive.

o=    conflict-scope: same structure as “scope&= #8221;

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:Tiruma= leswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The proposal works for me, is the plan to add 7, 8 and 9 status or ad= d a new “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Pick one and deactivate all the others based on= some criteria

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Activate all of them

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A084D91OPEXCLILMA3corp_-- From nobody Fri Dec 1 07:37:00 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B948129413 for ; Fri, 1 Dec 2017 07:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYT1ge1zQ_Hn for ; Fri, 1 Dec 2017 07:36:49 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73753129418 for ; Fri, 1 Dec 2017 07:36:47 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1512142606; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=qdykfGy4ceWkBmvvcCyCmdjlXC+j7kQKmwB8Cv rIMf0=; b=pfOhknU/VgtKufDNi7Q4CNszTqlbRTaMrX7F6DUA PyDMVDRo+mcTqrChscuqLSWaTMJjnGVeMNuS2Vn71VAUJAzkj5 nTfvGwXibidwgg2+o8wCd9ukkCR5+ICxgotmgbFkgoi0KsA/RB egel60Zaik21eZD/ev20fAzm9fFbMBU= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 6e7b_ab33_b2650ff8_bef0_4161_8695_e5b2a7884d9c; Fri, 01 Dec 2017 09:36:45 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 1 Dec 2017 08:36:24 -0700 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 1 Dec 2017 08:36:23 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 1 Dec 2017 08:36:23 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 1 Dec 2017 08:36:22 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Fri, 1 Dec 2017 15:36:21 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0282.007; Fri, 1 Dec 2017 15:36:21 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYIABxzqAgAANvYCAAAMmMA== Date: Fri, 1 Dec 2017 15:36:21 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:LUkzSWeq6qsitpmCA+RW1PcK9lgANmRsnRh6e7cv0ngNznPiLlA/qxsFXl7ztqK2UrQomR4Ic3DLs68jnVgL9mjkFm6b5H3hYBwq1sdSNpLO6Fw3QXK85MHjpdFLJAQZCCjfBywhnt6Wb7vU6q7CXOApA+2DzaIKKStZLRIQgzfx5ndnXNbhcR7TfPfDO/X67lJXNMzt0XXDpiByZ1PNShjLFHi27FcpaSoPxtvrVz4q045Sl81/vJeRv2a6UoWpRXuwA3LDc7d3713XQSXOXNon5gOQWkUSCaArUtV0UM0LIwzOC/xxUye5e+wAdm76giYR3mf0pzOggCWdlrh8NhOR3SFhVDx/5ZB6Y8T7qPA=; 5:QcnpENsT5hPwM6KcmoT4VxvwQV/r7gxA/TrXo53Q2YPooxOb5CS/Qx/TDvCUZvWMuUjmKsh3lWrLko4/Ku36xBIgVT2MMAAMkwqoMWQmN4Qy0UQYg3824yKdXDVnWPWRdQ49uzfAkTB4adOsbz7Y6xGGWgF03Su8gLlXkofMlwU=; 24:fERV+sRUyuRmknC1PRUgO30LBGoZE7AwUrpPnUd0w3WZ4wVaNPsdSdqEcRwJH8DRPecMOa59Opelwh5peyKtbKyeFjjAA24X1EGZzMRMkFs=; 7:2PjnqmOo9GHIQj5mZ0eaiMiuRK5XgPgCnskpQYSYTz7289rqyZ9umFuNqi7sYeZGvOUrA7RBut4gYPunst+fRnjbvpvbn7Dk4mQA6abOczZ2gItSUq7x+8AVjMDoxaFgS+ME3rJSxXcMc7BdovTINEAP6X/Q/QW0P+OhIf5zmzixRdBa6l/Wzw8/stsibpbooHEvrIfShEek7fPHJcO0f2CeQ3G0TdLjpPjpwJBuMOONnlphf8AFmhcDYmImY+xM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 20c1fe28-720c-45c5-6bbc-08d538d145fd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(32952001)(53754006)(51444003)(199003)(189002)(19609705001)(99286004)(81166006)(93886005)(53946003)(16200700003)(8676002)(5660300001)(54896002)(6306002)(81156014)(236005)(7736002)(106356001)(74316002)(9686003)(7696005)(966005)(110136005)(606006)(54356011)(2501003)(316002)(76176011)(66066001)(72206003)(53546010)(80792005)(97736004)(14454004)(86362001)(25786009)(478600001)(15650500001)(8936002)(561944003)(55016002)(102836003)(101416001)(6116002)(790700001)(3846002)(229853002)(2950100002)(6246003)(77096006)(53936002)(345774005)(6436002)(7110500001)(189998001)(6506006)(2900100001)(3280700002)(3660700001)(2906002)(10710500007)(68736007)(33656002)(105586002)(2420400007)(85282002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887046CA9B0D559A7B83EEEA390DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 20c1fe28-720c-45c5-6bbc-08d538d145fd X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 15:36:21.5099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6171> : inlines <6201> : streams <1771875> : uri <2543360> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:36:58 -0000 --_000_DM5PR16MB17887046CA9B0D559A7B83EEEA390DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We may want to further discuss the following points: 1. I don't see a conflict between a white-listed ACL and mitigation r= equest. When DDoS attack is in progress, white-listed traffic (white-list A= CL created using DOTS data channel) will be forwarded to the target network= without any processing by the mitigator, rest all other traffic will be sc= rubbed to detect and drop attack traffic. 2. Though the conflicting mitigation request is withdrawn or rejected= , it is still maintained by the DOTS server. The DOTS client should use GE= T (with or without Observe option) to learn if the conflict is resolved. Is= "retry-timer" really required ? 3. Conflicting mitigation scopes could mean client-A signals a target= IP address X but client-B signals multiple target IP addresses including X= . Client-B could be DDoS detector having higher visibility into the DDoS at= tack than a Web server (Client-A). Client-B will have higher precedence tha= n Client-A. -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, December 1, 2017 8:36 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB17887046CA9B0D559A7B83EEEA390DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We may wa= nt to further discuss the following points:

&nbs= p;

1.       I don’t see a conflict between a white-listed ACL and mitigation request. When DDoS attack is in progress, white-listed traff= ic (white-list ACL created using DOTS data channel) will be forwarded to th= e target network without any processing by the mitigator, rest all other traffic will be scrubbed to detect and dr= op attack traffic.  

<= span style=3D"mso-fareast-language:ZH-CN">2= .   &= nbsp;   Though the conflicting mitigation request is withdr= awn or rejected, it is still maintained by the DOTS server.  The DOTS = client should use GET (with or without Observe option) to learn if the conflict is resolved. Is "retry-timer" r= eally required ?

<= span style=3D"mso-fareast-language:ZH-CN">3= .   &= nbsp;   Conflicting mitigation scopes could mean client-A s= ignals a target IP address X but client-B signals multiple target IP addres= ses including X. Client-B could be DDoS detector having higher visibility into the DDoS attack than a Web server (= Client-A). Client-B will have higher precedence than Client-A.

=  <= /p>

-Tiru

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

      con= flict-cause:  Indicates the cause of the conflict.  The

     &nbs= p;   following values are defined:

 

     &nbs= p;   1:  Overlapping target prefixes

 

     &nbs= p;   2:  Conflicts with an existing white list

 

Are there any other codes that can be listed h= ere?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

&nbs= p;

If requir= ed “additional-status” can be added in future specifications; A= s you already know, DOTS protocol is extensible to define new standard and = vendor-specific parameters.

@Jon R= 11; Yes, ietf-dots-signal needs to be modified to include the mitigation st= atus parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks goo= d to me.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-status” param= eter, and given the current values defined in Table 2, I don’t see wh= ich status code to return when “additional-status” is set to &#= 8220;3 | DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are inactive”= . I’m afraid new status codes should be defined for this to work (e.g= ., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, we will need to = supply additional information to characterize the conflict (conflict-inform= ation). This information should be returned to all clients.

 

So, what about considering this direction?

-   Update the status table with these NEW codes:

o   7: Attack mitigation is withdrawn

o   8: Attack mitigation is rejected

-   Allow for including ‘additional-status’. Define &#= 8216;conflict-information’ under that parent; ‘conflict-informa= tion’ can include the following sub-parameters:

o   conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently inac= tive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently acti= ve.

=A7  3 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  All conflicting mitigation requests are i= nactive.

o   conflict-scope: same structure as “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The propo= sal works for me, is the plan to add 7, 8 and 9 status or add a new “= additional-status” parameter ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discarding all conflicti= ng requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one= .   

 

I do prefer to leave this to implementation/de= ployment as a policy to be supplied. That policy will instruct the dots ser= ver about the behavior to follow based one specific information that is available for a given deployment:  

=B7&n= bsp;      Pick one and deactivate all the others based on some criteria<= o:p>

=B7&n= bsp;      Activate all of them

=B7&n= bsp;      De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on premise DDoS mitigation syste= m) acting as DOTS clients and a web server with in-built DDoS detection cap= ability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector= (or IDMS) and there will be conflicting mitigation requests from different= DOTS clients, discarding all the mitigation requests from different client= s will make the mechanism not useful.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB17887046CA9B0D559A7B83EEEA390DM5PR16MB1788namp_-- From nobody Sun Dec 3 20:10:50 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9EC124B0A; Sun, 3 Dec 2017 20:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unpPTZoK2KUS; Sun, 3 Dec 2017 20:10:48 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D711200C1; Sun, 3 Dec 2017 20:10:48 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8368ED375BF98; Mon, 4 Dec 2017 04:10:44 +0000 (GMT) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 04:10:45 +0000 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.252]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 12:10:40 +0800 From: "Xialiang (Frank)" To: "draft-ietf-dots-architecture.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: My comments for DOTS architecture -05 draft: Thread-Index: AdNstbPSUKCaEZbQS0W62zNYk/U1wg== Date: Mon, 4 Dec 2017 04:10:40 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BC7B949DGGEML502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] My comments for DOTS architecture -05 draft: X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 04:10:49 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BC7B949DGGEML502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This version is already pretty mature and stable to go to next stage in my = personal opinion, some minor comments are as below: 1. In section 1.2, the sentence "as when aggregating intra-domain D= OTS client signals for inter-domain coordinated attack response" is not so = clear to me. Is it possible for the intra-domain coordinated attack respons= e use cases? 2. In section 2, you have mentioned both client (attack target) hea= lth information and efficacy information, which are the same in current pro= tocol draft. Can you clarify your definition of them? 3. For the whole document, please double check the Figure title. So= me of them are not align with the same style of capital of every word. 4. For data channel information, we have identifiers, BL/WL, filter= ing and provisioning now. But I don't think we had a crystal definition for= part of them, even the difference among them. More specifically, BL/WL vs = filtering, what is the provisioning? 5. In the beginning paragraphs of section 2.1 about DOTS operations= , the binding relation between signal and data channel is missed, no matter= they are really bound by DOTS agents ID (i.e., address, credential info, o= thers) or are not necessarily bound. 6. In the first paragraph of P9, an attack mitigation request does = not necessarily result in traffic redirection, right? 7. In Figure 13, "1" should be "2":) Thanks for your excellent work! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12BC7B949DGGEML502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This version is already pretty = mature and stable to go to next stage in my personal opinion, some minor co= mments are as below:

1.  &n= bsp;      In section 1.2, the sen= tence “as when aggregating intra-domain DOTS client signals for inter= -domain coordinated attack response” is not so clear to me. Is it pos= sible for the intra-domain coordinated attack response use cases?

2.  &n= bsp;      In section 2, you have = mentioned both client (attack target) health information and efficacy infor= mation, which are the same in current protocol draft. Can you clarify your = definition of them?

3.  &n= bsp;      For the whole document,= please double check the Figure title. Some of them are not align with the = same style of capital of every word.

4.  &n= bsp;      For data channel inform= ation, we have identifiers, BL/WL, filtering and provisioning now. But I do= n’t think we had a crystal definition for part of them, even the diff= erence among them. More specifically, BL/WL vs filtering, what is the provisioning?

5.  &n= bsp;      In the beginning paragr= aphs of section 2.1 about DOTS operations, the binding relation between sig= nal and data channel is missed, no matter they are really bound by DOTS age= nts ID (i.e., address, credential info, others) or are not necessarily bound.

6.  &n= bsp;      In the first paragraph = of P9, an attack mitigation request does not necessarily result in traffic = redirection, right?

7.  &n= bsp;      In Figure 13, “1&= #8221; should be “2”J

 

Thanks for your excellent work!=

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12BC7B949DGGEML502MBSchi_-- From nobody Sun Dec 3 21:41:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291A8126B7F for ; Sun, 3 Dec 2017 21:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfbSD09fPgM2 for ; Sun, 3 Dec 2017 21:41:03 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397B5126D45 for ; Sun, 3 Dec 2017 21:41:03 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D655EF16F058F for ; Mon, 4 Dec 2017 05:40:59 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 05:41:00 +0000 Received: from DGGEML509-MBX.china.huawei.com ([169.254.1.5]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 13:40:54 +0800 From: "dongyue (D)" To: dots Thread-Topic: DOTS requirement draft questions and comments Thread-Index: AdNswi4bM2GN9n2DT7qXe3+JdqRFGg== Date: Mon, 4 Dec 2017 05:40:54 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.147.99] Content-Type: multipart/alternative; boundary="_000_B82A8EC7D625074DBD6E89645AD1D26B01276BDCdggeml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] DOTS requirement draft questions and comments X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 05:41:05 -0000 --_000_B82A8EC7D625074DBD6E89645AD1D26B01276BDCdggeml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are a few questions/comments on the dots-requirement-07: * SIG-003: It says 'Peer DOTS agents SHOULD regularly send heartbea= ts to each other while a mitigation request is active'. But I think the hea= rtbeats should be send once the DOTS session has been established, no matte= r if a request is active or not. * SIG-003: it mentioned in the second paragraph that ' a DOTS serve= r might want to delay or cease heartbeat exchanges when an active DOTS clie= nt has not requested mitigation, in order to control load'. Firstly, 'delay= ' is a kind of time shift, it will not reduce the load, I recommend to repl= ace 'delay' with 'reduce the heartbeat frequency' or 'increase the heartbea= t interval'. Secondly, I am not clear why DOTS server want to cease heartbe= at? In this case, if the heartbeat has been ceased, the mitigation will be = automatically triggered! * SEC-004: In the first paragraph, the status is not a message from= DOTS client, I recommend it to be 'status request' Kind Regards, Yue --_000_B82A8EC7D625074DBD6E89645AD1D26B01276BDCdggeml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are a few questions/comments on the dots-requir= ement-07:

 

·         SIG-003: It says ‘Peer DOTS agents SHO= ULD regularly send heartbeats to each other while a mitigation request is a= ctive’. But I think the heartbeats should be send once the DOTS sessi= on has been established, no matter if a request is active or not.

 

·         SIG-003: it mentioned in the second paragrap= h that ‘ a DOTS server might want to delay or cease heartbeat exchang= es when an active DOTS client has not requested mitigation, in order to con= trol load’. Firstly, ‘delay’ is a kind of time shift, it will not reduce the load, I recommend to replace ‘= delay’ with ‘reduce the heartbeat frequency’ or ‘in= crease the heartbeat interval’. Secondly, I am not clear why DOTS ser= ver want to cease heartbeat? In this case, if the heartbeat has been ceased, the mitigation will be automatically triggered!

 

·         SEC-004: In the first paragraph, the status = is not a message from DOTS client, I recommend it to be ‘status reque= st’

 

 

Kind Regards,

Yue

--_000_B82A8EC7D625074DBD6E89645AD1D26B01276BDCdggeml509mbxchi_-- From nobody Sun Dec 3 23:18:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB212420B for ; Sun, 3 Dec 2017 23:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymrvxZfdnaRp for ; Sun, 3 Dec 2017 23:17:56 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F20120454 for ; Sun, 3 Dec 2017 23:17:56 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 640881207F9; Mon, 4 Dec 2017 08:17:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 3C54D60060; Mon, 4 Dec 2017 08:17:54 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 08:17:53 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYIABxzqAgAANvYCAAAMmMKJTpyIw Date: Mon, 4 Dec 2017 07:17:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A085640@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A085640OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 07:18:00 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A085640OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, Thank you for summarizing the pending points for discussion. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification We may want to further discuss the following points: 1. I don't see a conflict between a white-listed ACL and mitigation r= equest. When DDoS attack is in progress, white-listed traffic (white-list A= CL created using DOTS data channel) will be forwarded to the target network= without any processing by the mitigator, rest all other traffic will be sc= rubbed to detect and drop attack traffic. [Med] Agree with the description.. but when the whitelisted traffic include= s DDoS traffic there is "something" to be fixed. Consider that in a deploym= ent scenario the mitigator is also aware of the ACLs, but receives a signal= message for a resource that is whitelisted, those are two conflicting info= rmation that are available to the mitigator. Having a code signal this conf= lict wouldn't be appropriate here? Of course, we should not assume that all= mitigators are aware of ACLs, but if this the case, the DOTS server should= be able to do so. 2. Though the conflicting mitigation request is withdrawn or rejected= , it is still maintained by the DOTS server. The DOTS client should use GE= T (with or without Observe option) to learn if the conflict is resolved. Is= "retry-timer" really required ? [Med] The state is maintained for a given duration. So, sending GET message= s when that state is still alive, won't be helpful. Providing a hint to the= client to guide when it can place future requests for the same resource is= an optimization. It has also the side effect to prevent overloading the se= rver. When no "retry-timer" is returned, the client will behave as you described. 3. Conflicting mitigation scopes could mean client-A signals a target= IP address X but client-B signals multiple target IP addresses including X= . Client-B could be DDoS detector having higher visibility into the DDoS at= tack than a Web server (Client-A). Client-B will have higher precedence tha= n Client-A. [Med] Thanks. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, December 1, 2017 8:36 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A085640OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thank you for summarizing the pending points for= discussion.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

We may want to further discuss the following points:

 

1.       I don’t see a conflict between a white-listed ACL and mitigation request. When DDoS attack is in progr= ess, white-listed traffic (white-list ACL created using DOTS data channel) will be forwarded to the target network without a= ny processing by the mitigator, rest all other traffic will be scrubbed to = detect and drop attack traffic.  

[Med= ] Agree with the description.. but when the whitelisted traffic includes DD= oS traffic there is “something” to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but= receives a signal message for a resource that is whitelisted, those are tw= o conflicting information that are available to the mitigator. Having a cod= e signal this conflict wouldn’t be appropriate here? Of course, we should not assume that all mitigators a= re aware of ACLs, but if this the case, the DOTS server should be able to d= o so.

 

2.       Though the conflicting mitigation request is withdrawn or rej= ected, it is still maintained by the DOTS server.  The DOTS client sho= uld use GET (with or without Observe option) to learn if the conflict is resolved. Is "retry-timer" really re= quired ?

[Med= ] The state is maintained for a given duration. So, sending GET messages wh= en that state is still alive, won’t be helpful. Providing a hint to the client to guide when it can place future requests = for the same resource is an optimization. It has also the side effect to pr= event overloading the server.

 

When= no “retry-timer” is returned, the client will behave as you de= scribed.

 

3.       Conflicting mitigation scopes could mean client-A signals a t= arget IP address X but client-B signals multiple target IP addresses includ= ing X. Client-B could be DDoS detector having higher visibility into the DDoS attack than a Web server (Client-A)= . Client-B will have higher precedence than Client-A.

[Med= ] Thanks.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

   &= nbsp;  conflict-cause:  Indicates the cause of the conflict. = ; The

   &= nbsp;     following values are defined:

 

   &= nbsp;     1:  Overlapping target prefixes

 

   &= nbsp;     2:  Conflicts with an existing white lis= t

 

Are there any other codes that = can be listed here?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

 

If required “additional-status” can be added in future sp= ecifications; As you already know, DOTS protocol is extensible to define ne= w standard and vendor-specific parameters.

@Jon – Yes, ietf-dots-signal needs to be modified to include th= e mitigation status parameters.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks good to me.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-stat= us” parameter, and given the current values defined in Table 2, I don= ’t see which status code to return when “additional-status̶= 1; is set to “3 | DOTS Server has detected conflicting mitigation reque= sts from different DOTS clients.  All conflicting mitigation requests = are inactive”. I’m afraid new status codes should be defined fo= r this to work (e.g., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, w= e will need to supply additional information to characterize the conflict (= conflict-information). This information should be returned to all clients.

 

So, what about considering this= direction?

-   Update the status table with these NEW codes:

o=    7: Attack mitigation is withdrawn

o=    8: Attack mitigation is rejected

-   Allow for including ‘additional-status= 217;. Define ‘conflict-information’ under that parent; ‘c= onflict-information’ can include the following sub-parameters:

o=    conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently active.

=A7  3 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  All conflicting mitigation= requests are inactive.

o=    conflict-scope: same structure as “scope&= #8221;

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:Tiruma= leswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The proposal works for me, is the plan to add 7, 8 and 9 status or ad= d a new “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Pick one and deactivate all the others based on= some criteria

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Activate all of them

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A085640OPEXCLILMA3corp_-- From nobody Mon Dec 4 00:21:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42B81241F5 for ; Mon, 4 Dec 2017 00:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RryjIV8i2zHy for ; Mon, 4 Dec 2017 00:20:58 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B76120046 for ; Mon, 4 Dec 2017 00:20:57 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1512375656; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=HN2J2UdRKOMCQYXkgbVYQR+43OCC5D0b44PSMK HfUso=; b=aLb/u5frTtasfd9yN8ikeX4Dj4XF0ssMii1bsqB1 3K9Fg9OGbceA/4gyLeQv+KadVKCwAkeytY2H38wy4wH1YnXWOr XktwxbzgeJvMDUbVa58pj9AV0JiKcDBOsCmn1fNm7W/NTBggP0 7AgUAj8VnhZ7fthP9O/AHqNXDhTpA/I= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 0a3a_8069_0f7f7f9a_dae5_4403_bdb5_30bf006ba15b; Mon, 04 Dec 2017 02:20:54 -0600 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 4 Dec 2017 03:20:53 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 4 Dec 2017 03:20:51 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 4 Dec 2017 03:20:51 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 4 Dec 2017 03:20:50 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 4 Dec 2017 08:20:49 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0282.010; Mon, 4 Dec 2017 08:20:49 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYIABxzqAgAANvYCAAAMmMIAEMPWAgAAPGHA= Date: Mon, 4 Dec 2017 08:20:49 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A085640@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A085640@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:hNKGrx4XNm4XcIfjioC620H12VVPJEjOiimmpRgNqkdnzcXcVS3H00zE7P7VfKqzoorY7edou4mXpqw/Qi9zK5f+iiw/oEY8Unbm8RNwevJsQORrV9q1N28EAj0w0jZIEFz8kjKDSxu0RSn4YJ5bMY+YYjsKDsqa9TswjR0emSZU3VctVVmbAhZhqwDk1SViflCqB4ukzFjsGyDuVYI8kHuIi67DLnsdHX5kdc5dwmyErH0oMpzlgwPcy+HlLLdvT6xUsn6DveZfrQDwpcFjzhsnsQWFe2I81+6wPBp86E/9gNFvNwIv+Hd+Zpf+x2TISd74yJS+Jy6I5zDyJWqKSu7Z1AObvYihKObwVqMSJGg=; 5:sQL2nFAkmkBBgJTm0VV01ukl7oUj1Xq+QA3J2FX7ngwLlJemIPXuQzHZVGR/cUl1a25tTP3YDUCH92yZWKARHpH8QOS4UYUDwkudLSk7FOR38ECxUa57yKoBJ30Jy0Fom1MeOGyMu0LnkmqURc1nvu2gsf83urasIPjRK73T/W4=; 24:aflYxqG8/dNPvV5zythGOVUIjPH7ABPmCxREnqqBLOI08GpGz9N6UBBoWKMn3OKtqAlR5og8fnv9bI2Z02hJJ5kdmhicWC0FxX+SreNf+gU=; 7:/EOLGCYo5yyMesMOK16xXJPVQ4EzXC73ngkz3Bmilhk+EoHJRrlIp6qNb9N4tkU5Wzy+agRxHoCqYPJwilgTr+zFlhvo4exPOY9XelUtYvBhDemCNOw4KZXKXOrhZBmsTLBZ4Q3rWAaJGWU2SR7GKLxvc+Yzrdc8EzVfrQTlb9olFexFPHOuLN2bWWPR24Jlv3PTiwVgAxVPejbCUA6G53x3AhDcTmM6enfwieMS3JOReWed5JIn11EKZyyBvYA2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a5e5cfe8-ab68-4028-c96c-08d53aefed58 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231022)(10201501046)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 051158ECBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(51444003)(189002)(53754006)(32952001)(199003)(345774005)(15650500001)(76176011)(81156014)(7696005)(54896002)(6306002)(9326002)(3660700001)(9686003)(80792005)(105586002)(74316002)(8676002)(68736007)(86362001)(72206003)(110136005)(54356011)(3280700002)(2900100001)(97736004)(81166006)(106356001)(8936002)(14454004)(790700001)(6116002)(2906002)(2501003)(3846002)(966005)(10710500007)(102836003)(53936002)(236005)(19609705001)(16200700003)(53946003)(7110500001)(478600001)(316002)(99286004)(77096006)(55016002)(101416001)(25786009)(33656002)(2950100002)(189998001)(606006)(53546010)(229853002)(5660300001)(7736002)(2420400007)(6436002)(6506006)(561944003)(6246003)(93886005)(66066001)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178871A58B8F7215B64A8ABEEA3C0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a5e5cfe8-ab68-4028-c96c-08d53aefed58 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2017 08:20:49.4688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6171> : inlines <6203> : streams <1772131> : uri <2544875> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 08:21:03 -0000 --_000_DM5PR16MB178871A58B8F7215B64A8ABEEA3C0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, December 4, 2017 12:48 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, Thank you for summarizing the pending points for discussion. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification We may want to further discuss the following points: 1. I don't see a conflict between a white-listed ACL and mitigation r= equest. When DDoS attack is in progress, white-listed traffic (white-list A= CL created using DOTS data channel) will be forwarded to the target network= without any processing by the mitigator, rest all other traffic will be sc= rubbed to detect and drop attack traffic. [Med] Agree with the description.. but when the whitelisted traffic include= s DDoS traffic there is "something" to be fixed. Consider that in a deploym= ent scenario the mitigator is also aware of the ACLs, but receives a signal= message for a resource that is whitelisted, [TR] Source addresses are white-listed to a resource (or target) but the ta= rget will not be white-listed to receive traffic from any source. Mitigati= on request will only carry the target addresses/prefixes and not the attack= er prefixes/addresses. I don't see a conflict. those are two conflicting information that are available to the mitigator. = Having a code signal this conflict wouldn't be appropriate here? Of course,= we should not assume that all mitigators are aware of ACLs, but if this th= e case, the DOTS server should be able to do so. 2. Though the conflicting mitigation request is withdrawn or rejected= , it is still maintained by the DOTS server. The DOTS client should use GE= T (with or without Observe option) to learn if the conflict is resolved. Is= "retry-timer" really required ? [Med] The state is maintained for a given duration. So, sending GET message= s when that state is still alive, won't be helpful. Providing a hint to the= client to guide when it can place future requests for the same resource is= an optimization. [TR] How will the DOTS server know ahead of time when the conflict will be = resolved to suggest a hint to the client ? -Tiru It has also the side effect to prevent overloading the server. When no "retry-timer" is returned, the client will behave as you described. 3. Conflicting mitigation scopes could mean client-A signals a target= IP address X but client-B signals multiple target IP addresses including X= . Client-B could be DDoS detector having higher visibility into the DDoS at= tack than a Web server (Client-A). Client-B will have higher precedence tha= n Client-A. [Med] Thanks. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, December 1, 2017 8:36 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB178871A58B8F7215B64A8ABEEA3C0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

Please se= e inline [TR]

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, December 4, 2017 12:48 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

Thank you for summarizing the pendin= g points for discussion.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

We may wa= nt to further discuss the following points:

&nbs= p;

1.       I don’t see a conflict between a white-listed= ACL and mitigation request. When DDoS attack is in progress, white-listed = traffic (white-list ACL created using DOTS data channel) will be forwarded to the target network without any processi= ng by the mitigator, rest all other traffic will be scrubbed to detect and = drop attack traffic.  

[Med] Agree with th= e description.. but when the whitelisted traffic includes DDoS traffic ther= e is “something” to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but receive= s a signal message for a resource that is whitelisted,

&nbs= p;

[TR] Sour= ce addresses are white-listed to a resource (or target) but the target will= not be white-listed to receive traffic from any source.  Mitigation r= equest will only carry the target addresses/prefixes and not the attacker prefixes/addresses. I don’t see a conflict.

&nbs= p;

those are two confl= icting information that are available to the mitigator. Having a code signa= l this conflict wouldn’t be appropriate here? Of course, we should not assume that all mitigators are aware of ACLs, but= if this the case, the DOTS server should be able to do so.

 

2.       Though the conflicting mitigation request is withdr= awn or rejected, it is still maintained by the DOTS server.  The DOTS = client should use GET (with or without Observe option) to learn if the conflict is resolved. Is "retry-timer" r= eally required ?

[Med] The state is = maintained for a given duration. So, sending GET messages when that state i= s still alive, won’t be helpful. Providing a hint to the client to guide when it can place future requests for the same reso= urce is an optimization.

&nbs= p;

[TR] How = will the DOTS server know ahead of time when the conflict will be resolved = to suggest a hint to the client ?

&nbs= p;

-Tiru

&nbs= p;

It has also the sid= e effect to prevent overloading the server.

 

When no “retr= y-timer” is returned, the client will behave as you described.

 

3.       Conflicting mitigation scopes could mean client-A s= ignals a target IP address X but client-B signals multiple target IP addres= ses including X. Client-B could be DDoS detector having higher visibility into the DDoS attack than a Web server (= Client-A). Client-B will have higher precedence than Client-A.

[Med] Thanks.<= /o:p>

 

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

      con= flict-cause:  Indicates the cause of the conflict.  The

     &nbs= p;   following values are defined:

 

     &nbs= p;   1:  Overlapping target prefixes

 

     &nbs= p;   2:  Conflicts with an existing white list

 

Are there any other codes that can be listed h= ere?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

&nbs= p;

If requir= ed “additional-status” can be added in future specifications; A= s you already know, DOTS protocol is extensible to define new standard and = vendor-specific parameters.

@Jon R= 11; Yes, ietf-dots-signal needs to be modified to include the mitigation st= atus parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks goo= d to me.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-status” param= eter, and given the current values defined in Table 2, I don’t see wh= ich status code to return when “additional-status” is set to &#= 8220;3 | DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are inactive”= . I’m afraid new status codes should be defined for this to work (e.g= ., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, we will need to = supply additional information to characterize the conflict (conflict-inform= ation). This information should be returned to all clients.

 

So, what about considering this direction?

-   Update the status table with these NEW codes:

o   7: Attack mitigation is withdrawn

o   8: Attack mitigation is rejected

-   Allow for including ‘additional-status’. Define &#= 8216;conflict-information’ under that parent; ‘conflict-informa= tion’ can include the following sub-parameters:

o   conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently inac= tive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently acti= ve.

=A7  3 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  All conflicting mitigation requests are i= nactive.

o   conflict-scope: same structure as “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The propo= sal works for me, is the plan to add 7, 8 and 9 status or add a new “= additional-status” parameter ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discarding all conflicti= ng requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one= .   

 

I do prefer to leave this to implementation/de= ployment as a policy to be supplied. That policy will instruct the dots ser= ver about the behavior to follow based one specific information that is available for a given deployment:  

=B7&n= bsp;      Pick one and deactivate all the others based on some criteria<= o:p>

=B7&n= bsp;      Activate all of them

=B7&n= bsp;      De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on premise DDoS mitigation syste= m) acting as DOTS clients and a web server with in-built DDoS detection cap= ability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector= (or IDMS) and there will be conflicting mitigation requests from different= DOTS clients, discarding all the mitigation requests from different client= s will make the mechanism not useful.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB178871A58B8F7215B64A8ABEEA3C0DM5PR16MB1788namp_-- From nobody Mon Dec 4 01:05:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA24124207 for ; Mon, 4 Dec 2017 01:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6eUE_1B8EzQ for ; Mon, 4 Dec 2017 01:05:13 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F5D1201FA for ; Mon, 4 Dec 2017 01:05:12 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id C4C3FA0403; Mon, 4 Dec 2017 10:05:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 917421A0086; Mon, 4 Dec 2017 10:05:10 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 10:05:10 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYIABxzqAgAANvYCAAAMmMIAEMPWAgAAPGHCiV8ZbEA== Date: Mon, 4 Dec 2017 09:05:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08571F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A085640@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A08571FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 09:05:17 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A08571FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 4 d=E9cembre 2017 09:21 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, December 4, 2017 12:48 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, Thank you for summarizing the pending points for discussion. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification We may want to further discuss the following points: 1. I don't see a conflict between a white-listed ACL and mitigation r= equest. When DDoS attack is in progress, white-listed traffic (white-list A= CL created using DOTS data channel) will be forwarded to the target network= without any processing by the mitigator, rest all other traffic will be sc= rubbed to detect and drop attack traffic. [Med] Agree with the description.. but when the whitelisted traffic include= s DDoS traffic there is "something" to be fixed. Consider that in a deploym= ent scenario the mitigator is also aware of the ACLs, but receives a signal= message for a resource that is whitelisted, [TR] Source addresses are white-listed to a resource (or target) but the ta= rget will not be white-listed to receive traffic from any source. [Med] The example is as follows: - Accept all incoming traffic from this particular source (S1) to this t= arget. - It happens that source (S1) is the origin of a DDoS Mitigation request will only carry the target addresses/prefixes and not t= he attacker prefixes/addresses. I don't see a conflict. [Med] The conflict is not included in the mitigation request, but it is det= ermined as a result of processing the request. In reference to the example = above, the server/mitigator will determine that the target is getting DDoSe= d by S1. So the conflict is between allowing all the traffic from S1 to the= target (ACL) or filter the traffic from S1 (mitigation request). those are two conflicting information that are available to the mitigator. = Having a code signal this conflict wouldn't be appropriate here? Of course,= we should not assume that all mitigators are aware of ACLs, but if this th= e case, the DOTS server should be able to do so. 2. Though the conflicting mitigation request is withdrawn or rejected= , it is still maintained by the DOTS server. The DOTS client should use GE= T (with or without Observe option) to learn if the conflict is resolved. Is= "retry-timer" really required ? [Med] The state is maintained for a given duration. So, sending GET message= s when that state is still alive, won't be helpful. Providing a hint to the= client to guide when it can place future requests for the same resource is= an optimization. [TR] How will the DOTS server know ahead of time when the conflict will be = resolved to suggest a hint to the client ? [Med] It can rely on the pending mitigation lifetime. -Tiru It has also the side effect to prevent overloading the server. When no "retry-timer" is returned, the client will behave as you described. 3. Conflicting mitigation scopes could mean client-A signals a target= IP address X but client-B signals multiple target IP addresses including X= . Client-B could be DDoS detector having higher visibility into the DDoS at= tack than a Web server (Client-A). Client-B will have higher precedence tha= n Client-A. [Med] Thanks. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, December 1, 2017 8:36 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A08571FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 4 d=E9cembre 2017 09:21
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

Please see inline [TR]

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, December 4, 2017 12:48 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

Thank you for summarizing the pending points for= discussion.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

We may want to further discuss the following points:

 

1.       I don̵= 7;t see a conflict between a white-listed ACL and mitigation request. When = DDoS attack is in progress, white-listed traffic (white-list ACL created us= ing DOTS data channel) will be forwarded to the target network without any processing by the mitigator, rest all other= traffic will be scrubbed to detect and drop attack traffic.  

[Med= ] Agree with the description.. but when the whitelisted traffic includes DD= oS traffic there is “something” to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but= receives a signal message for a resource that is whitelisted,

 

[TR] Source addresses are white-listed to a resource (or target) but = the target will not be white-listed to receive traffic from any source.

[Med= ] The example is as follows:

-    Accept all incoming traffic from this particular source (S1) to this ta= rget.

-    It happens that source (S1) is the origin of a DDoS

 

 Mitigation request will only carry the target addresses/prefixe= s and not the attacker prefixes/addresses. I don’t see a conflict.

[Med= ] The conflict is not included in the mitigation request, but it is determi= ned as a result of processing the request. In reference to the example above, the server/mitigator will determine that the target = is getting DDoSed by S1. So the conflict is between allowing all the traffi= c from S1 to the target (ACL) or filter the traffic from S1 (mitigation req= uest).  

 

thos= e are two conflicting information that are available to the mitigator. Havi= ng a code signal this conflict wouldn’t be appropriate here? Of course, we should not assume that all mitigators are aware of ACL= s, but if this the case, the DOTS server should be able to do so.

 

2.       Though the= conflicting mitigation request is withdrawn or rejected, it is still maint= ained by the DOTS server.  The DOTS client should use GET (with or wit= hout Observe option) to learn if the conflict is resolved. Is "retry-timer" really required ?

[Med= ] The state is maintained for a given duration. So, sending GET messages wh= en that state is still alive, won’t be helpful. Providing a hint to the client to guide when it can place future requests = for the same resource is an optimization.

 

[TR] How will the DOTS server know ahead of time when the conflict wi= ll be resolved to suggest a hint to the client ?

[Med= ] It can rely on the pending mitigation lifetime.

 

-Tiru

 

It h= as also the side effect to prevent overloading the server.

 

When= no “retry-timer” is returned, the client will behave as you de= scribed.

 

3.       Conflictin= g mitigation scopes could mean client-A signals a target IP address X but c= lient-B signals multiple target IP addresses including X. Client-B could be= DDoS detector having higher visibility into the DDoS attack than a Web server (Client-A). Client-B will have high= er precedence than Client-A.

[Med= ] Thanks.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

   &= nbsp;  conflict-cause:  Indicates the cause of the conflict. = ; The

   &= nbsp;     following values are defined:

 

   &= nbsp;     1:  Overlapping target prefixes

 

   &= nbsp;     2:  Conflicts with an existing white lis= t

 

Are there any other codes that = can be listed here?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

 

If required “additional-status” can be added in future sp= ecifications; As you already know, DOTS protocol is extensible to define ne= w standard and vendor-specific parameters.

@Jon – Yes, ietf-dots-signal needs to be modified to include th= e mitigation status parameters.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks good to me.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-stat= us” parameter, and given the current values defined in Table 2, I don= ’t see which status code to return when “additional-status̶= 1; is set to “3 | DOTS Server has detected conflicting mitigation reque= sts from different DOTS clients.  All conflicting mitigation requests = are inactive”. I’m afraid new status codes should be defined fo= r this to work (e.g., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, w= e will need to supply additional information to characterize the conflict (= conflict-information). This information should be returned to all clients.

 

So, what about considering this= direction?

-   Update the status table with these NEW codes:

o=    7: Attack mitigation is withdrawn

o=    8: Attack mitigation is rejected

-   Allow for including ‘additional-status= 217;. Define ‘conflict-information’ under that parent; ‘c= onflict-information’ can include the following sub-parameters:

o=    conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently active.

=A7  3 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  All conflicting mitigation= requests are inactive.

o=    conflict-scope: same structure as “scope&= #8221;

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:Tiruma= leswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The proposal works for me, is the plan to add 7, 8 and 9 status or ad= d a new “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Pick one and deactivate all the others based on= some criteria

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Activate all of them

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A08571FOPEXCLILMA3corp_-- From nobody Mon Dec 4 01:26:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2715126E64 for ; Mon, 4 Dec 2017 01:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41kGuCD7rXPU for ; Mon, 4 Dec 2017 01:26:34 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC64126B7E for ; Mon, 4 Dec 2017 01:26:33 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1512379556; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=v8EtV7WMi0iWOhoyje/jmjb1/EgDo9DuW2rUDl Pm/1g=; b=KhQnMZ6GFHgCBRJGrjdvryH0kZy+O1LIGqL1AUD9 0esl5VcPhRFh7J2VIOOTcHaocUyxACJMILEKR1ERFglE/ePZ+9 OkMwgAH4pn1kNnhHzfAjF9tV0wp6aHuTj2/ZmdMLvvKwEf04nk EGJcHJ4Q9n+B42K/h3ONw5Y4IZ0/ElM= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 0a3a_a86c_7c2fe5b5_36a9_405c_b575_b215789b6e28; Mon, 04 Dec 2017 03:25:54 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 4 Dec 2017 04:25:43 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 4 Dec 2017 04:25:43 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 4 Dec 2017 04:25:41 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 4 Dec 2017 09:25:40 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0282.010; Mon, 4 Dec 2017 09:25:40 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYIABxzqAgAANvYCAAAMmMIAEMPWAgAAPGHCAAA7ggIAABA+Q Date: Mon, 4 Dec 2017 09:25:40 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A085640@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08571F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A08571F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:1uEUBQ1pqn5DnsnCyRPS//UkYnWPAS77/wESaGPt/Pdl0kmJRS3Koki28OPY+cNxmHBP21+04Q9B5/xfTiXOEBNAzYkHGsHuGK7BpmhqRjW/2eHugGCzvsrIYJ0PRCsGg8nd0/0KiHbiO/jLFHd+aTwcNbKLLB27Niz8LbnH15Wby4IYbIIjY0KkYfIPFYYDdL5BvKUmxv0Wv1MzCIsYqM8zu8hFcBWDtxUxfhhqUtfAqo/T3q0HXvzL3/KU+7pDcSBhc3tl8AcKgnOkbpfkEaDx6b1tsf0NyzcMTnpdKAoqBf00W98kMH9KlREtDHN7ajJNjeCyboF3Biu9eA60CPI2g9TXfqc6W5IxvFmbaSQ=; 5:eniDNjVlms1m0BXTQ9RQKi5C4vsNLO+UxB3pb2TWMpuk+fmqcOyeDixW4mDgaFAaYQ5A9hYji2T99THmU4sCoARGeaxY7w7HkX20wZembpYAHuEblrZAxzunVKyiH70unNfLLexKD/wkyKyHl/05VspcmTf6P6QLyhYf1GrkFlI=; 24:OSC5F+qFJ/hpq0oCTZ1S7dlc2CMzu8N8LLyt1asKh7pW6zBdDqxAF5CADRWv8JWy9lccp0Dt4vWmhzcQk50SkEHqCcxaIJXbI87MtaP/6rA=; 7:FWb86LbvpKdM6i6tzDaq7jRDuecB6wY3po0jJ0E0Hkfm9RlW9KL7AX0UaIE4IcB38NOjypn0kXn6x5A2O4F1KVG+ePqeffPO/fWRBNP9dgNPB/PcNZ4skjlU8GmqlObCabVDj8NoOjr7qemcbOfRcHNcl26QyCMogNcYOW17JNzFUtAqNGZMRs2mOIPVgFkMK0CQBYj3fkh3HSpjGV6n59fDeHdheFTPO5v+wU+KfJ7hQH06Me91X2murHsyagDz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cfa42d3d-dd84-4672-56ed-08d53af8fc98 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 051158ECBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(32952001)(51444003)(53754006)(189002)(199003)(3280700002)(55016002)(53546010)(2420400007)(15650500001)(2900100001)(606006)(86362001)(68736007)(345774005)(14454004)(3660700001)(8676002)(54356011)(236005)(229853002)(478600001)(66066001)(6506006)(16200700003)(6246003)(105586002)(966005)(106356001)(10710500007)(54896002)(53936002)(6306002)(2906002)(7736002)(81156014)(99286004)(72206003)(9686003)(81166006)(93886005)(6436002)(77096006)(2501003)(316002)(3846002)(80792005)(74316002)(7110500001)(2950100002)(53946003)(76176011)(189998001)(5660300001)(101416001)(19609705001)(102836003)(6116002)(790700001)(33656002)(110136005)(7696005)(25786009)(97736004)(9326002)(561944003)(8936002)(85282002)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17888E62AF1E8BA27D6F8A70EA3C0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cfa42d3d-dd84-4672-56ed-08d53af8fc98 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2017 09:25:40.5514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6171> : inlines <6203> : streams <1772136> : uri <2544903> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 09:26:39 -0000 --_000_DM5PR16MB17888E62AF1E8BA27D6F8A70EA3C0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, December 4, 2017 2:35 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 4 d=E9cembre 2017 09:21 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, December 4, 2017 12:48 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, Thank you for summarizing the pending points for discussion. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification We may want to further discuss the following points: 1. I don't see a conflict between a white-listed ACL and mitigation r= equest. When DDoS attack is in progress, white-listed traffic (white-list A= CL created using DOTS data channel) will be forwarded to the target network= without any processing by the mitigator, rest all other traffic will be sc= rubbed to detect and drop attack traffic. [Med] Agree with the description.. but when the whitelisted traffic include= s DDoS traffic there is "something" to be fixed. Consider that in a deploym= ent scenario the mitigator is also aware of the ACLs, but receives a signal= message for a resource that is whitelisted, [TR] Source addresses are white-listed to a resource (or target) but the ta= rget will not be white-listed to receive traffic from any source. [Med] The example is as follows: - Accept all incoming traffic from this particular source (S1) to this ta= rget. - It happens that source (S1) is the origin of a DDoS Mitigation request will only carry the target addresses/prefixes and not t= he attacker prefixes/addresses. I don't see a conflict. [Med] The conflict is not included in the mitigation request, but it is det= ermined as a result of processing the request. In reference to the example = above, the server/mitigator will determine that the target is getting DDoSe= d by S1. So the conflict is between allowing all the traffic from S1 to the= target (ACL) or filter the traffic from S1 (mitigation request). those are two conflicting information that are available to the mitigator. = Having a code signal this conflict wouldn't be appropriate here? Of course,= we should not assume that all mitigators are aware of ACLs, but if this th= e case, the DOTS server should be able to do so. [TR2] Got it, thanks. We should add a line to clarify; the DDoS mitigation = detects source addresses/prefixes in the white-listed ACLs are attacking th= e target. 2. Though the conflicting mitigation request is withdrawn or rejected= , it is still maintained by the DOTS server. The DOTS client should use GE= T (with or without Observe option) to learn if the conflict is resolved. Is= "retry-timer" really required ? [Med] The state is maintained for a given duration. So, sending GET message= s when that state is still alive, won't be helpful. Providing a hint to the= client to guide when it can place future requests for the same resource is= an optimization. [TR] How will the DOTS server know ahead of time when the conflict will be = resolved to suggest a hint to the client ? [Med] It can rely on the pending mitigation lifetime. [TR2] If the server response is lost, the client will re-send the mitigatio= n request before the "retry-timer" expires but the server will discard the = request. The client will never receive a response, especially with long mit= igation lifetime (the recommended default value is 60 minutes). -Tiru It has also the side effect to prevent overloading the server. When no "retry-timer" is returned, the client will behave as you described. 3. Conflicting mitigation scopes could mean client-A signals a target= IP address X but client-B signals multiple target IP addresses including X= . Client-B could be DDoS detector having higher visibility into the DDoS at= tack than a Web server (Client-A). Client-B will have higher precedence tha= n Client-A. [Med] Thanks. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, December 1, 2017 8:36 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB17888E62AF1E8BA27D6F8A70EA3C0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, December 4, 2017 2:35 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 4 d=E9cembre 2017 09:21
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

Please se= e inline [TR]

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, December 4, 2017 12:48 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

Thank you for summarizing the pendin= g points for discussion.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

We may wa= nt to further discuss the following points:

&nbs= p;

1. &nb= sp;     I don’t see a confl= ict between a white-listed ACL and mitigation request. When DDoS attack is = in progress, white-listed traffic (white-list ACL created using DOTS data c= hannel) will be forwarded to the target network without any processing by the mitigator, rest all other traffic wi= ll be scrubbed to detect and drop attack traffic.  <= /p>

[Med] Agree with th= e description.. but when the whitelisted traffic includes DDoS traffic ther= e is “something” to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but receive= s a signal message for a resource that is whitelisted,

&nbs= p;

[TR] Sour= ce addresses are white-listed to a resource (or target) but the target will= not be white-listed to receive traffic from any source.

[Med] The example i= s as follows:

-Accept all incoming traffic from this particular source (S1) = to this target.

-It happens that source (S1) is the origin of a DDoS

 

 Mit= igation request will only carry the target addresses/prefixes and not the a= ttacker prefixes/addresses. I don’t see a conflict.

[Med] The conflict = is not included in the mitigation request, but it is determined as a result= of processing the request. In reference to the example above, the server/mitigator will determine that the target is gett= ing DDoSed by S1. So the conflict is between allowing all the traffic from = S1 to the target (ACL) or filter the traffic from S1 (mitigation request). =  

&nbs= p;

those are two confl= icting information that are available to the mitigator. Having a code signa= l this conflict wouldn’t be appropriate here? Of course, we should not assume that all mitigators are aware of ACLs, but= if this the case, the DOTS server should be able to do so.

&nbs= p;

[TR2] Got= it, thanks. We should add a line to clarify; the DDoS mitigation detects s= ource addresses/prefixes in the white-listed ACLs are attacking the target.=

 

2. &nb= sp;     Though the conflicting mi= tigation request is withdrawn or rejected, it is still maintained by the DO= TS server.  The DOTS client should use GET (with or without Observe op= tion) to learn if the conflict is resolved. Is "retry-timer" really required ?

[Med] The state is = maintained for a given duration. So, sending GET messages when that state i= s still alive, won’t be helpful. Providing a hint to the client to guide when it can place future requests for the same reso= urce is an optimization.

&nbs= p;

[TR] How = will the DOTS server know ahead of time when the conflict will be resolved = to suggest a hint to the client ?

[Med] It can rely o= n the pending mitigation lifetime.

&nbs= p;

[TR2] If the server response is lost, the client will re-send the mitigation requ= est before the “retry-timer” expires but the server will discar= d the request. The client will never receive a response, especially with lo= ng mitigation lifetime (the recommended default value is 60 minutes).

&nbs= p;

-Tiru

&nbs= p;

It has also the sid= e effect to prevent overloading the server.

 

When no “retr= y-timer” is returned, the client will behave as you described.

 

3. &nb= sp;     Conflicting mitigation sc= opes could mean client-A signals a target IP address X but client-B signals= multiple target IP addresses including X. Client-B could be DDoS detector = having higher visibility into the DDoS attack than a Web server (Client-A). Client-B will have higher preced= ence than Client-A.

[Med] Thanks.<= /o:p>

 

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

      con= flict-cause:  Indicates the cause of the conflict.  The

     &nbs= p;   following values are defined:

 

     &nbs= p;   1:  Overlapping target prefixes

 

     &nbs= p;   2:  Conflicts with an existing white list

 

Are there any other codes that can be listed h= ere?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

&nbs= p;

If requir= ed “additional-status” can be added in future specifications; A= s you already know, DOTS protocol is extensible to define new standard and = vendor-specific parameters.

@Jon R= 11; Yes, ietf-dots-signal needs to be modified to include the mitigation st= atus parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks goo= d to me.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-status” param= eter, and given the current values defined in Table 2, I don’t see wh= ich status code to return when “additional-status” is set to &#= 8220;3 | DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are inactive”= . I’m afraid new status codes should be defined for this to work (e.g= ., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, we will need to = supply additional information to characterize the conflict (conflict-inform= ation). This information should be returned to all clients.

 

So, what about considering this direction?

-   Update the status table with these NEW codes:

o   7: Attack mitigation is withdrawn

o   8: Attack mitigation is rejected

-   Allow for including ‘additional-status’. Define &#= 8216;conflict-information’ under that parent; ‘conflict-informa= tion’ can include the following sub-parameters:

o   conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently inac= tive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently acti= ve.

=A7  3 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  All conflicting mitigation requests are i= nactive.

o   conflict-scope: same structure as “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The propo= sal works for me, is the plan to add 7, 8 and 9 status or add a new “= additional-status” parameter ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discarding all conflicti= ng requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one= .   

 

I do prefer to leave this to implementation/de= ployment as a policy to be supplied. That policy will instruct the dots ser= ver about the behavior to follow based one specific information that is available for a given deployment:  

=B7&n= bsp;      Pick one and deactivate all the others based on some criteria<= o:p>

=B7&n= bsp;      Activate all of them

=B7&n= bsp;      De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on premise DDoS mitigation syste= m) acting as DOTS clients and a web server with in-built DDoS detection cap= ability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector= (or IDMS) and there will be conflicting mitigation requests from different= DOTS clients, discarding all the mitigation requests from different client= s will make the mechanism not useful.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB17888E62AF1E8BA27D6F8A70EA3C0DM5PR16MB1788namp_-- From nobody Mon Dec 4 01:41:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B42124217 for ; Mon, 4 Dec 2017 01:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Y7C2wGIq69 for ; Mon, 4 Dec 2017 01:41:16 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE31A1241F5 for ; Mon, 4 Dec 2017 01:41:15 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 50394A0A31; Mon, 4 Dec 2017 10:41:14 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 2048D1A0069; Mon, 4 Dec 2017 10:41:14 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 10:41:13 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYIABxzqAgAANvYCAAAMmMIAEMPWAgAAPGHCAAA7ggIAABA+QolfRewA= Date: Mon, 4 Dec 2017 09:41:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A085784@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901 d369c9$20ad07f 0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019d01d36aaf$14213ce0$3c63b6a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084D91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A085640@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08571F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A085784OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 09:41:21 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A085784OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, OK to add a line to clarify the DDoS mitigation detects source addresses/pr= efixes in the white-listed ACLs are attacking the target. I will make a pro= posal. You said: =3D=3D [TR2] If the server response is lost, the client will re-send the mitigatio= n request before the "retry-timer" expires but the server will discard the = request. The client will never receive a response, especially with long mit= igation lifetime (the recommended default value is 60 minutes). =3D=3D Good point. I guess you are referring to "Any retransmission of the same mi= tigation request before the expiry of this timer will be discarded by the D= OTS server." Please note that the text does not say "silently discarded". W= hat about? OLD: Any retransmission of the same mitigation request before the expiry of this= timer will be discarded by the DOTS server. NEW: Any retransmission of the same mitigation request before the expiry of this= timer is likely to be rejected by the DOTS server for the same reasons. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : lundi 4 d=E9cembre 2017 10:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, December 4, 2017 2:35 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 4 d=E9cembre 2017 09:21 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, December 4, 2017 12:48 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, Thank you for summarizing the pending points for discussion. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification We may want to further discuss the following points: 1. I don't see a conflict between a white-listed ACL and mitigation r= equest. When DDoS attack is in progress, white-listed traffic (white-list A= CL created using DOTS data channel) will be forwarded to the target network= without any processing by the mitigator, rest all other traffic will be sc= rubbed to detect and drop attack traffic. [Med] Agree with the description.. but when the whitelisted traffic include= s DDoS traffic there is "something" to be fixed. Consider that in a deploym= ent scenario the mitigator is also aware of the ACLs, but receives a signal= message for a resource that is whitelisted, [TR] Source addresses are white-listed to a resource (or target) but the ta= rget will not be white-listed to receive traffic from any source. [Med] The example is as follows: - Accept all incoming traffic from this particular source (S1) to this ta= rget. - It happens that source (S1) is the origin of a DDoS Mitigation request will only carry the target addresses/prefixes and not t= he attacker prefixes/addresses. I don't see a conflict. [Med] The conflict is not included in the mitigation request, but it is det= ermined as a result of processing the request. In reference to the example = above, the server/mitigator will determine that the target is getting DDoSe= d by S1. So the conflict is between allowing all the traffic from S1 to the= target (ACL) or filter the traffic from S1 (mitigation request). those are two conflicting information that are available to the mitigator. = Having a code signal this conflict wouldn't be appropriate here? Of course,= we should not assume that all mitigators are aware of ACLs, but if this th= e case, the DOTS server should be able to do so. [TR2] Got it, thanks. We should add a line to clarify; the DDoS mitigation = detects source addresses/prefixes in the white-listed ACLs are attacking th= e target. 2. Though the conflicting mitigation request is withdrawn or rejected= , it is still maintained by the DOTS server. The DOTS client should use GE= T (with or without Observe option) to learn if the conflict is resolved. Is= "retry-timer" really required ? [Med] The state is maintained for a given duration. So, sending GET message= s when that state is still alive, won't be helpful. Providing a hint to the= client to guide when it can place future requests for the same resource is= an optimization. [TR] How will the DOTS server know ahead of time when the conflict will be = resolved to suggest a hint to the client ? [Med] It can rely on the pending mitigation lifetime. [TR2] If the server response is lost, the client will re-send the mitigatio= n request before the "retry-timer" expires but the server will discard the = request. The client will never receive a response, especially with long mit= igation lifetime (the recommended default value is 60 minutes). -Tiru It has also the side effect to prevent overloading the server. When no "retry-timer" is returned, the client will behave as you described. 3. Conflicting mitigation scopes could mean client-A signals a target= IP address X but client-B signals multiple target IP addresses including X= . Client-B could be DDoS detector having higher visibility into the DDoS at= tack than a Web server (Client-A). Client-B will have higher precedence tha= n Client-A. [Med] Thanks. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, December 1, 2017 8:36 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, So would we therefore be looking at [Med] Please check out -10. module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw target-protocol* uint8 +--rw target-fqdn* inet:domain-name +--rw target-uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 +--ro mitigation-start? decimal64 +--ro status? int32 +--ro bytes-dropped? int32 +--ro bps-dropped? int32 +--ro pkts-dropped? int32 +--ro pps-dropped? int32 +--ro conflict-information? +--ro conflict-status? int32 +--ro conflict-scope? [Med] -10 does not include the conflict scope (yet) but does include a conf= lict-cause. The reason for this is that the server may have more than two c= onflicting requests. So not sure what to return in the conflict-scope in su= ch case. +--ro target-ip* inet:ip-address +--ro target-prefix* inet:ip-prefix +--ro target-port-range* [lower-port upper-port] | +--ro lower-port? inet:port-number | +--ro upper-port? inet:port-number +--ro target-protocol* uint8 +--ro target-fqdn* inet:domain-name +--ro target-uri* inet:uri +--ro alias-name* string [Med] Please note that -10 does not include conflict-code for address/uri/f= qdn/ports because I'm not sure we can consider two mitigation requests comi= ng from two dots clients as conflicting because each of them is indicating = a distinct target fqdn/uri/port/address. Things are cleared for overlapping= prefixes, but I think we need to think more about the other cases. Where conflict-scope 'hints' at what the conflicting item is? - What happens when the conflict is caused by a filter/acl definition - sho= uld this also be a conflict-scope definition? [Med] There is one code for this in -10: conflict-cause: Indicates the cause of the conflict. The following values are defined: 1: Overlapping target prefixes 2: Conflicts with an existing white list Are there any other codes that can be listed here? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 11:14 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A085784OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

OK to add a line to clarify the= DDoS mitigation detects source addresses/prefixes in the white-listed ACLs= are attacking the target. I will make a proposal.

 

You said:

=3D=3D

[TR2] If the ser= ver response is lost, the client will re-send the mitigation request before= the “retry-timer” expires but the server will discard the requ= est. The client will never receive a response, especially with long mitigation lifetime (the recommended default value is 60 minutes= ).

=3D=3D

 

Good point. I guess you are ref= erring to “Any retransmission of the same mitigation request before t= he expiry of this timer will be discarded by the DOTS server.” Please note that the text does not say “silently disc= arded”. What about?

 

OLD:

Any retransmission of the same = mitigation request before the expiry of this timer will be discarded by the= DOTS server.

 

NEW:

Any retransmission of the same = mitigation request before the expiry of this timer is likely to be rejected= by the DOTS server for the same reasons.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : lundi 4 d=E9cembre 2017 10:26
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

Please see inline [TR2]

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, December 4, 2017 2:35 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 4 d=E9cembre 2017 09:21
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

Please see inline [TR]

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, December 4, 2017 12:48 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

Thank you for summarizing the pending points for= discussion.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 1 d=E9cembre 2017 16:36
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

We may want to further discuss the following points:

 

1.       I don̵= 7;t see a conflict between a white-listed ACL and mitigation request. When = DDoS attack is in progress, white-listed traffic (white-list ACL created us= ing DOTS data channel) will be forwarded to the target network without any processing by the mitigator, rest all other= traffic will be scrubbed to detect and drop attack traffic.  

[Med= ] Agree with the description.. but when the whitelisted traffic includes DD= oS traffic there is “something” to be fixed. Consider that in a deployment scenario the mitigator is also aware of the ACLs, but= receives a signal message for a resource that is whitelisted,

 

[TR] Source addresses are white-listed to a resource (or target) but = the target will not be white-listed to receive traffic from any source.

[Med= ] The example is as follows:

-   Accept all incoming = traffic from this particular source (S1) to this target.

-   It happens that sour= ce (S1) is the origin of a DDoS

 

 Mitigation request will only carry the target addresses/prefixe= s and not the attacker prefixes/addresses. I don’t see a conflict.

[Med= ] The conflict is not included in the mitigation request, but it is determi= ned as a result of processing the request. In reference to the example above, the server/mitigator will determine that the target = is getting DDoSed by S1. So the conflict is between allowing all the traffi= c from S1 to the target (ACL) or filter the traffic from S1 (mitigation req= uest).  

 

thos= e are two conflicting information that are available to the mitigator. Havi= ng a code signal this conflict wouldn’t be appropriate here? Of course, we should not assume that all mitigators are aware of ACL= s, but if this the case, the DOTS server should be able to do so.

 

[TR2] Got it, thanks. We should add a line to clarify; the DDoS mitig= ation detects source addresses/prefixes in the white-listed ACLs are attack= ing the target.

 

2.       Though the= conflicting mitigation request is withdrawn or rejected, it is still maint= ained by the DOTS server.  The DOTS client should use GET (with or wit= hout Observe option) to learn if the conflict is resolved. Is "retry-timer" really required ?

[Med= ] The state is maintained for a given duration. So, sending GET messages wh= en that state is still alive, won’t be helpful. Providing a hint to the client to guide when it can place future requests = for the same resource is an optimization.

 

[TR] How will the DOTS server know ahead of time when the conflict wi= ll be resolved to suggest a hint to the client ?

[Med= ] It can rely on the pending mitigation lifetime.

 

[TR2] If the ser= ver response is lost, the client will re-send the mitigation request before= the “retry-timer” expires but the server will discard the requ= est. The client will never receive a response, especially with long mitigation lifetime (the recommended default value is 60 minutes= ).

 

-Tiru

 

It h= as also the side effect to prevent overloading the server.

 

When= no “retry-timer” is returned, the client will behave as you de= scribed.

 

3.       Conflictin= g mitigation scopes could mean client-A signals a target IP address X but c= lient-B signals multiple target IP addresses including X. Client-B could be= DDoS detector having higher visibility into the DDoS attack than a Web server (Client-A). Client-B will have high= er precedence than Client-A.

[Med= ] Thanks.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, December 1, 2017 8:36 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 1 d=E9cembre 2017 15:17
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

So woul= d we therefore be looking at

[Med] Please check out -10.

&n= bsp;

   module: ietf-dots= -signal

     =   +--rw mitigation-scope

     =      +--rw client-identifier*   binary

     =      +--rw scope* [mitigation-id]=

     =         +--rw mitigation-id &nb= sp;      int32

     =         +--rw target-ip*  =          inet:ip-address=

     =         +--rw target-prefix* &n= bsp;     inet:ip-prefix

     =         +--rw target-port-range* [lo= wer-port upper-port]

     =         |  +--rw lower-port&nbs= p;   inet:port-number

     =         |  +--rw upper-port?&nb= sp;  inet:port-number

     =         +--rw target-protocol* =     uint8

     =         +--rw target-fqdn* &nbs= p;       inet:domain-name

     =         +--rw target-uri*  = ;        inet:uri

     =         +--rw alias-name*  = ;        string

     =         +--rw lifetime?  &= nbsp;         int32

     =         +--ro mitigation-start? = ;   decimal64

     =         +--ro status?  &nb= sp;           int32<= /o:p>

     =         +--ro bytes-dropped? &n= bsp;     int32

     =         +--ro bps-dropped? &nbs= p;       int32

     =         +--ro pkts-dropped? &nb= sp;      int32

     =         +--ro pps-dropped? &nbs= p;       int32

     =         +--ro conflict-information?<= o:p>

     =            +--ro conf= lict-status?     int32

     =            +--ro conf= lict-scope?

 

[Med] -10 does not include the = conflict scope (yet) but does include a conflict-cause. The reason for this= is that the server may have more than two conflicting requests. So not sure what to return in the conflict-scope in such case.

 

     =             &nb= sp; +--ro target-ip*        &nb= sp;  inet:ip-address

     =             &nb= sp; +--ro target-prefix*       inet:ip-pr= efix

     =             &nb= sp; +--ro target-port-range* [lower-port upper-port]<= /p>

     =             &nb= sp; |  +--ro lower-port?   inet:port-number

     =             &n= bsp;|  +--ro upper-port?   inet:port-number

     =             &nb= sp; +--ro target-protocol*     uint8

     =             &nb= sp; +--ro target-fqdn*         = inet:domain-name

     =             &nb= sp; +--ro target-uri*        &n= bsp; inet:uri

     =             &nb= sp; +--ro alias-name*        &n= bsp; string<= /span>

&nbs= p;

[Med] Please note that -10 does= not include conflict-code for address/uri/fqdn/ports because I’m not= sure we can consider two mitigation requests coming from two dots clients as conflicting because each of them is indicating a disti= nct target fqdn/uri/port/address. Things are cleared for overlapping prefix= es, but I think we need to think more about the other cases.

 

Where c= onflict-scope ‘hints’ at what the conflicting item is?

- What = happens when the conflict is caused by a filter/acl definition – shou= ld this also be a conflict-scope definition?

[Med] There is one code for thi= s in -10:

 

   &= nbsp;  conflict-cause:  Indicates the cause of the conflict. = ; The

   &= nbsp;     following values are defined:

 

   &= nbsp;     1:  Overlapping target prefixes

 

   &= nbsp;     2:  Conflicts with an existing white lis= t

 

Are there any other codes that = can be listed here?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 11:14
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,

 

If required “additional-status” can be added in future sp= ecifications; As you already know, DOTS protocol is extensible to define ne= w standard and vendor-specific parameters.

@Jon – Yes, ietf-dots-signal needs to be modified to include th= e mitigation status parameters.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks good to me.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-stat= us” parameter, and given the current values defined in Table 2, I don= ’t see which status code to return when “additional-status̶= 1; is set to “3 | DOTS Server has detected conflicting mitigation reque= sts from different DOTS clients.  All conflicting mitigation requests = are inactive”. I’m afraid new status codes should be defined fo= r this to work (e.g., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, w= e will need to supply additional information to characterize the conflict (= conflict-information). This information should be returned to all clients.

 

So, what about considering this= direction?

-   Update the status table with these NEW codes:

o=    7: Attack mitigation is withdrawn

o=    8: Attack mitigation is rejected

-   Allow for including ‘additional-status= 217;. Define ‘conflict-information’ under that parent; ‘c= onflict-information’ can include the following sub-parameters:

o=    conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently active.

=A7  3 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  All conflicting mitigation= requests are inactive.

o=    conflict-scope: same structure as “scope&= #8221;

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:Tiruma= leswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The proposal works for me, is the plan to add 7, 8 and 9 status or ad= d a new “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Pick one and deactivate all the others based on= some criteria

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Activate all of them

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A085784OPEXCLILMA3corp_-- From nobody Mon Dec 4 12:35:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2A3128BB6 for ; Mon, 4 Dec 2017 12:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl7XxYuZ0-xa for ; Mon, 4 Dec 2017 12:35:21 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A20128B8F for ; Mon, 4 Dec 2017 12:35:21 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB4KZKDv006005 for ; Mon, 4 Dec 2017 15:35:20 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu vB4KZKDv006005 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1512419720; bh=WYz183O7etBVfvdEA+xH6LPGPMHbjWSDdFpWErunzeY=; h=From:To:Subject:Date:From; b=Gg2OTvw5F8I/GKJpzdfCyFzR7dbijmP0MPpWez8tXBmSnJ0B/RluV7bSlt3RPLU1w sQ8MhaRssbhWHR+4Wh5zhs3fh6WpxYlyV2bI6wO5Jp9Y0dD/wgOt2SNsI+Sbbwg8qj x8iCD9KHKh8QoBbmC3AwyrUbYgvD5AfFsgcF9GpM= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB4KZGGc003967 for ; Mon, 4 Dec 2017 15:35:16 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 15:35:15 -0500 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Draft DOTS minutes from IETF 100 Thread-Index: AdNtPzZQq6kl0WtnRtClMxbLmAhGTQ== Date: Mon, 4 Dec 2017 20:35:15 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131339CCC@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Draft DOTS minutes from IETF 100 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 20:35:23 -0000 Hello! Draft minutes from the DOTS meeting at IETF 100 can be found here: https://datatracker.ietf.org/meeting/100/materials/minutes-100-dots/ Thanks to Liang Xia for taking them. If you have any corrections, please send them to the WG chairs. Regards, Roman and Tobias From nobody Tue Dec 5 08:06:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9D12956C for ; Tue, 5 Dec 2017 08:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkyhOsaAdfOK for ; Tue, 5 Dec 2017 08:06:03 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263A8127342 for ; Tue, 5 Dec 2017 08:06:03 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB5G14nN030736; Tue, 5 Dec 2017 11:05:44 -0500 Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0054.outbound.protection.outlook.com [216.32.180.54]) by mx0a-00196b01.pphosted.com with ESMTP id 2ensmj8f79-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Dec 2017 11:05:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QUQUzspPDuXgnIaV9mmR07xeIrED+YE1teKDt+q2644=; b=ZbOJJ+PHt3drDSziDUq8bb7NQ05C6nVZFwX0+9vqPpy2z1LnHynhSK4CqEb4+r/9HQCK/+8jIudGbCDNgQ/Wwt1/kUtPoPiWjkQUluGDjNJfzFlVj9mSP57Mgzq8A2I93AoF0KtRliQkIlAQs/mOkXTbY+PsdevJgyv+AUQwJ/c= Received: from CO2PR01MB1989.prod.exchangelabs.com (10.166.90.142) by CO2PR01MB1990.prod.exchangelabs.com (10.166.90.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Tue, 5 Dec 2017 16:05:40 +0000 Received: from CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) by CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) with mapi id 15.20.0282.012; Tue, 5 Dec 2017 16:05:40 +0000 From: "Mortensen, Andrew" To: "dongyue (D)" CC: dots Thread-Topic: [Dots] DOTS requirement draft questions and comments Thread-Index: AdNswi4bM2GN9n2DT7qXe3+JdqRFGgBILXwA Date: Tue, 5 Dec 2017 16:05:39 +0000 Message-ID: <00A452AB-9438-47E7-9319-6B2224CA9777@arbor.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:11e:1000:10:151f:25a9:7fa2:c689] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR01MB1990; 6:9bM8E24Eu8FAyHa9f2S3Y5YASzISrwsvkhqeuYcnvp8ltFDZuhELGLIlKjBy87Co8xADTricjOY4PY2L89eeA9VBQVI4ed65wt9YNZlUlV7TJ96WE0TF6WQwFaybfp2FrVioE98lXGojJbSKmdh6B4kX4c0Xn+JBRO+EVP7aDoMoD1p4Qj1Km3TGd6FZAw91pvdrjNpOeSaMjHdBj9xKIVGJt9pVbYD3l6xlOCOsA2YnHkJj7znXSig61+sCdnT4bIw/uPPO3W9+vpVskHoy7F0xf2QzTY9dwjjKnU1+qJxX1NRVXsNt+piHylRw+7/2ML7EtaAL9hanKLA6M3JJAyow9NCjro9aMjCxOXXERGA=; 5:DZ2vFDlMPtweRF54avJvLfdGSEzJtdeXhred4tS8SSat3RZc1MMqanYWBadKGm7awC2JNHgZNT0icdt2oQ+1wY9xYslU/LsKLd8WqF2wvMOUAP+xJY2POeZSJPwCN7sslv55cDpKvm3DgDqNbF2hA3hhoVBKGCmIlMUF6CFNlbk=; 24:ug3nNjjJ+YZJ9U7pZlew1Zss5LJ4KqeTz6UFE1nh0ObV3k7+cyjPnu+a5kLH2UgEd+2nEFtZ/2701va8j9C+30wfP8PS30T0ySnRKbzojts=; 7:J27rSiMeoc47C6QND4K/GpqBN8sEatcofF4LtA9pJeuykdqf0n23GZGhfAlwV9EabQtZriDvjHzQZppr7kymdpF9OPSNaST00rzhyAjqFDcGAJAFIRvDzavsIju9JmVnMQR37jU1cFmd7exLo/G9zoAgrbxQW6pEpAPzA4Yq0KdXGwJjSYFjRTTs+snxVL7Dlbi4pJK7PTAuNF3WEaTWXEvJI2jhRktQESV34ZP4+BeQf+zoVobSjHaWbXSKHsIr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4ec4a046-1354-4143-3e8f-08d53bfa07dd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:CO2PR01MB1990; x-ms-traffictypediagnostic: CO2PR01MB1990: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(50582790962513)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231022)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011); SRVR:CO2PR01MB1990; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO2PR01MB1990; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(189002)(24454002)(199003)(86362001)(6246003)(53936002)(2906002)(3280700002)(97736004)(3660700001)(229853002)(2950100002)(82746002)(99286004)(14454004)(77096006)(4326008)(83716003)(6916009)(7736002)(6436002)(68736007)(76176011)(5660300001)(6486002)(6506006)(316002)(25786009)(101416001)(478600001)(8676002)(81166006)(33656002)(2900100001)(189998001)(81156014)(236005)(53546010)(606006)(6512007)(54896002)(102836003)(8936002)(106356001)(6306002)(6116002)(105586002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB1990; H:CO2PR01MB1989.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_00A452AB943847E793196B2224CA9777arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4ec4a046-1354-4143-3e8f-08d53bfa07dd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 16:05:39.9002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB1990 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050232 Archived-At: Subject: Re: [Dots] DOTS requirement draft questions and comments X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 16:06:06 -0000 --_000_00A452AB943847E793196B2224CA9777arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBTZWUgbXkgcmVzcG9uc2VzIGlubGluZS4NCg0KYW5k cmV3DQoNCg0KT24gRGVjIDQsIDIwMTcsIGF0IDEyOjQwIEFNLCBkb25neXVlIChEKSA8ZG9uZ3l1 ZTZAaHVhd2VpLmNvbTxtYWlsdG86ZG9uZ3l1ZTZAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIZXJl IGFyZSBhIGZldyBxdWVzdGlvbnMvY29tbWVudHMgb24gdGhlIGRvdHMtcmVxdWlyZW1lbnQtMDc6 DQoNCuKAoiAgICAgICAgIFNJRy0wMDM6IEl0IHNheXMg4oCYUGVlciBET1RTIGFnZW50cyBTSE9V TEQgcmVndWxhcmx5IHNlbmQgaGVhcnRiZWF0cyB0byBlYWNoIG90aGVyIHdoaWxlIGEgbWl0aWdh dGlvbiByZXF1ZXN0IGlzIGFjdGl2ZeKAmS4gQnV0IEkgdGhpbmsgdGhlIGhlYXJ0YmVhdHMgc2hv dWxkIGJlIHNlbmQgb25jZSB0aGUgRE9UUyBzZXNzaW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLCBu byBtYXR0ZXIgaWYgYSByZXF1ZXN0IGlzIGFjdGl2ZSBvciBub3QuDQoNClRoZSBjdXJyZW50IGZv cm0gb2YgdGhpcyByZXF1aXJlbWVudCBpcyB0aGUgb3V0Y29tZSBvZiBkaXNjdXNzaW9ucyBmb2xs b3dpbmcgSUVURiA5OSwgaW4gd2hpY2ggaXQgYmVjYW1lIGFwcGFyZW50IHRoYXQgYSB6ZXJvIGhl YXJ0YmVhdCBtb2RlIHdhcyBkZXNpcmFibGUuIFBsZWFzZSBzZWU6DQoNCjxodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTkvbWF0ZXJpYWxzL3NsaWRlcy05OS1kb3RzLWRvdHMt aGFja2F0aG9uLXJlcG9ydC8+DQoNClNwZWNpZmljYWxseSwgdGhlIHNsaWRlIHRpdGxlZCDigJxM ZXNzb25zIGxlYXJuZWQgKDMvMynigJ06IOKAnFplcm8gaGVhcnRiZWF0IG1vZGUgc2hvdWxkIGJl IGFsbG93ZWTigJ0uDQoNCg0K4oCiICAgICAgICAgU0lHLTAwMzogaXQgbWVudGlvbmVkIGluIHRo ZSBzZWNvbmQgcGFyYWdyYXBoIHRoYXQg4oCYIGEgRE9UUyBzZXJ2ZXIgbWlnaHQgd2FudCB0byBk ZWxheSBvciBjZWFzZSBoZWFydGJlYXQgZXhjaGFuZ2VzIHdoZW4gYW4gYWN0aXZlIERPVFMgY2xp ZW50IGhhcyBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24sIGluIG9yZGVyIHRvIGNvbnRyb2wgbG9h ZOKAmS4gRmlyc3RseSwg4oCYZGVsYXnigJkgaXMgYSBraW5kIG9mIHRpbWUgc2hpZnQsIGl0IHdp bGwgbm90IHJlZHVjZSB0aGUgbG9hZCwgSSByZWNvbW1lbmQgdG8gcmVwbGFjZSDigJhkZWxheeKA mSB3aXRoIOKAmHJlZHVjZSB0aGUgaGVhcnRiZWF0IGZyZXF1ZW5jeeKAmSBvciDigJhpbmNyZWFz ZSB0aGUgaGVhcnRiZWF0IGludGVydmFs4oCZLg0KDQpXZSBjYW4gcmVwbGFjZSB0aGUg4oCcZGVs YXnigJ0gdGVybS4NCg0KDQoNClNlY29uZGx5LCBJIGFtIG5vdCBjbGVhciB3aHkgRE9UUyBzZXJ2 ZXIgd2FudCB0byBjZWFzZSBoZWFydGJlYXQ/IEluIHRoaXMgY2FzZSwgaWYgdGhlIGhlYXJ0YmVh dCBoYXMgYmVlbiBjZWFzZWQsIHRoZSBtaXRpZ2F0aW9uIHdpbGwgYmUgYXV0b21hdGljYWxseSB0 cmlnZ2VyZWQhDQoNClRyaWdnZXJpbmcgbWl0aWdhdGlvbiBvbiBsb3NzIG9mIGhlYXJ0YmVhdCBp cyBvbmUgcG9zc2libGUgbW9kZSBvZiBkZXBsb3ltZW50LiBJdCBpcyBub3QgdGhlIG9ubHkgbWVj aGFuaXNtIGZvciByZXF1ZXN0aW5nIG1pdGlnYXRpb24uIEF0IGxlYXN0IGFzIGRlc2NyaWJlZCBp biB0aGUgRE9UUyBhcmNoaXRlY3R1cmUsIGl0J3MgYWxzbyBiYXNlZCBvbiB0aGUgbG9zcyBvZiBo ZWFydGJlYXQgZnJvbSB0aGUgY2xpZW50LCBub3QgdGhlIHNlcnZlci4NCg0KDQrigKIgICAgICAg ICBTRUMtMDA0OiBJbiB0aGUgZmlyc3QgcGFyYWdyYXBoLCB0aGUgc3RhdHVzIGlzIG5vdCBhIG1l c3NhZ2UgZnJvbSBET1RTIGNsaWVudCwgSSByZWNvbW1lbmQgaXQgdG8gYmUg4oCYc3RhdHVzIHJl cXVlc3TigJkNCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgY2hhbmdlIGltcHJvdmVzIHRoZSBjbGFy aXR5IG9mIHRoYXQgcGFyYWdyYXBoLiBDb21wYXJlIHRoZSBjdXJyZW50IGZvcm06DQoNCuKAnERP VFMgc2VydmVycyBNVVNUIGF1dGhvcml6ZSBhbGwgbWVzc2FnZXMgZnJvbSBET1RTIGNsaWVudHMg d2hpY2ggcGVydGFpbiB0b+KApnN0YXR1cy7igJ0NCg0Kd2l0aCB0aGUgY2hhbmdlIHlvdeKAmXJl IHByb3Bvc2luZzoNCg0K4oCcRE9UUyBzZXJ2ZXJzIE1VU1QgYXV0aG9yaXplIGFsbCBtZXNzYWdl cyBmcm9tIERPVFMgY2xpZW50cyB3aGljaCBwZXJ0YWluIHRv4oCmc3RhdHVzIHJlcXVlc3RzLuKA nQ0KDQpUbyBtZSwgdGhlIGNoYW5nZSBoYXMgdGhlIGVmZmVjdCBvZiByZXF1aXJpbmcgYXV0aG9y aXphdGlvbiBvZiBhbGwgbWVzc2FnZXMgKmFib3V0KiBzdGF0dXMgcmVxdWVzdHMsIGFzIG9wcG9z ZWQgdG8gbWVzc2FnZXMgYWJvdXQgc3RhdHVzLg0KDQo= --_000_00A452AB943847E793196B2224CA9777arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLiBTZWUgbXkgcmVzcG9uc2VzIGlubGluZS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFuZHJldzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMgNCwg MjAxNywgYXQgMTI6NDAgQU0sIGRvbmd5dWUgKEQpICZsdDs8YSBocmVmPSJtYWlsdG86ZG9uZ3l1 ZTZAaHVhd2VpLmNvbSIgY2xhc3M9IiI+ZG9uZ3l1ZTZAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlv bjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSGVyZSBhcmUgYSBmZXcgcXVlc3Rpb25zL2Nv bW1lbnRzIG9uIHRoZSBkb3RzLXJlcXVpcmVtZW50LTA3OjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgdGV4dC1pbmRlbnQ6IC0xOHB0OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IFN5bWJvbDsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPsK3PHNwYW4gc3R5bGU9ImZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj5TSUctMDAzOg0KIEl0IHNheXMg4oCY UGVlciBET1RTIGFnZW50cyBTSE9VTEQgcmVndWxhcmx5IHNlbmQgaGVhcnRiZWF0cyB0byBlYWNo IG90aGVyIHdoaWxlIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFjdGl2ZeKAmS4gQnV0IEkgdGhp bmsgdGhlIGhlYXJ0YmVhdHMgc2hvdWxkIGJlIHNlbmQgb25jZSB0aGUgRE9UUyBzZXNzaW9uIGhh cyBiZWVuIGVzdGFibGlzaGVkLCBubyBtYXR0ZXIgaWYgYSByZXF1ZXN0IGlzIGFjdGl2ZSBvciBu b3QuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+VGhlIGN1cnJlbnQgZm9ybSBvZiB0aGlzIHJlcXVpcmVtZW50IGlz IHRoZSBvdXRjb21lIG9mIGRpc2N1c3Npb25zIGZvbGxvd2luZyBJRVRGIDk5LCBpbiB3aGljaCBp dCBiZWNhbWUgYXBwYXJlbnQgdGhhdCBhIHplcm8gaGVhcnRiZWF0IG1vZGUgd2FzIGRlc2lyYWJs ZS4gUGxlYXNlIHNlZTo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu PiZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTkvbWF0 ZXJpYWxzL3NsaWRlcy05OS1kb3RzLWRvdHMtaGFja2F0aG9uLXJlcG9ydC8iIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9tYXRlcmlhbHMvc2xpZGVzLTk5 LWRvdHMtZG90cy1oYWNrYXRob24tcmVwb3J0LzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5TcGVjaWZpY2FsbHksIHRoZSBzbGlkZSB0aXRsZWQg4oCcTGVz c29ucyBsZWFybmVkICgzLzMp4oCdOiDigJxaZXJvIGhlYXJ0YmVhdCBtb2RlIHNob3VsZCBiZSBh bGxvd2Vk4oCdLjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv c3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDs8L3NwYW4+PC9k aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0IDM2 cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IHRl eHQtaW5kZW50OiAtMThwdDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBT eW1ib2w7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj7CtzxzcGFuIHN0eWxlPSJmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+U0lHLTAwMzoNCiBpdCBtZW50aW9uZWQgaW4gdGhl IHNlY29uZCBwYXJhZ3JhcGggdGhhdCDigJggYSBET1RTIHNlcnZlciBtaWdodCB3YW50IHRvIGRl bGF5IG9yIGNlYXNlIGhlYXJ0YmVhdCBleGNoYW5nZXMgd2hlbiBhbiBhY3RpdmUgRE9UUyBjbGll bnQgaGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdhdGlvbiwgaW4gb3JkZXIgdG8gY29udHJvbCBsb2Fk 4oCZLiBGaXJzdGx5LCDigJhkZWxheeKAmSBpcyBhIGtpbmQgb2YgdGltZSBzaGlmdCwgaXQgd2ls bCBub3QgcmVkdWNlIHRoZQ0KIGxvYWQsIEkgcmVjb21tZW5kIHRvIHJlcGxhY2Ug4oCYZGVsYXni gJkgd2l0aCDigJhyZWR1Y2UgdGhlIGhlYXJ0YmVhdCBmcmVxdWVuY3nigJkgb3Ig4oCYaW5jcmVh c2UgdGhlIGhlYXJ0YmVhdCBpbnRlcnZhbOKAmS48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+V2UgY2FuIHJlcGxhY2UgdGhlIOKA nGRlbGF54oCdIHRlcm0uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0xOHB0OyIgY2xhc3M9 IiI+DQpTZWNvbmRseSwgSSBhbSBub3QgY2xlYXIgd2h5IERPVFMgc2VydmVyIHdhbnQgdG8gY2Vh c2UgaGVhcnRiZWF0PyBJbiB0aGlzIGNhc2UsIGlmIHRoZSBoZWFydGJlYXQgaGFzIGJlZW4gY2Vh c2VkLCB0aGUgbWl0aWdhdGlvbiB3aWxsIGJlIGF1dG9tYXRpY2FsbHkgdHJpZ2dlcmVkITwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5UcmlnZ2VyaW5nIG1pdGlnYXRpb24gb24gbG9zcyBvZiBoZWFydGJlYXQgaXMgb25lIHBvc3Np YmxlIG1vZGUgb2YgZGVwbG95bWVudC4gSXQgaXMgbm90IHRoZSBvbmx5IG1lY2hhbmlzbSBmb3Ig cmVxdWVzdGluZyBtaXRpZ2F0aW9uLiBBdCBsZWFzdCBhcyBkZXNjcmliZWQgaW4gdGhlIERPVFMg YXJjaGl0ZWN0dXJlLCBpdCdzIGFsc28gYmFzZWQgb24gdGhlIGxvc3Mgb2YgaGVhcnRiZWF0IGZy b20gdGhlIGNsaWVudCwgbm90IHRoZSBzZXJ2ZXIuPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIiPiZu YnNwOzwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0xOHB0OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IFN5bWJvbDsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPsK3PHNwYW4gc3R5 bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj5TRUMtMDA0Og0KIEluIHRo ZSBmaXJzdCBwYXJhZ3JhcGgsIHRoZSBzdGF0dXMgaXMgbm90IGEgbWVzc2FnZSBmcm9tIERPVFMg Y2xpZW50LCBJIHJlY29tbWVuZCBpdCB0byBiZSDigJhzdGF0dXMgcmVxdWVzdOKAmTwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj5JIGRvbuKAmXQgdGhpbmsgdGhhdCBjaGFuZ2UgaW1wcm92ZXMgdGhlIGNsYXJpdHkgb2YgdGhh dCBwYXJhZ3JhcGguIENvbXBhcmUgdGhlIGN1cnJlbnQgZm9ybTo8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAnERPVFMgc2VydmVycyBNVVNUIGF1dGhvcml6ZSBh bGwgbWVzc2FnZXMgZnJvbSBET1RTIGNsaWVudHMgd2hpY2ggcGVydGFpbiB0b+KApnN0YXR1cy7i gJ08L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PndpdGggdGhlIGNoYW5n ZSB5b3XigJlyZSBwcm9wb3Npbmc6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi Pjwvc3Bhbj7igJxET1RTIHNlcnZlcnMgTVVTVCBhdXRob3JpemUgYWxsIG1lc3NhZ2VzIGZyb20g RE9UUyBjbGllbnRzIHdoaWNoIHBlcnRhaW4gdG/igKZzdGF0dXMgcmVxdWVzdHMu4oCdPC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UbyBtZSwgdGhlIGNoYW5nZSBoYXMg dGhlIGVmZmVjdCBvZiByZXF1aXJpbmcgYXV0aG9yaXphdGlvbiBvZiBhbGwgbWVzc2FnZXMgKmFi b3V0KiBzdGF0dXMgcmVxdWVzdHMsIGFzIG9wcG9zZWQgdG8gbWVzc2FnZXMgYWJvdXQgc3RhdHVz LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_00A452AB943847E793196B2224CA9777arbornet_-- From nobody Tue Dec 5 09:33:00 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A272F126CF6; Tue, 5 Dec 2017 09:32:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151249517961.23082.5298126760710075311@ietfa.amsl.com> Date: Tue, 05 Dec 2017 09:32:59 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 17:33:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-08.txt Pages : 20 Date : 2017-12-05 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-08 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 5 09:35:30 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAE9127871; Tue, 5 Dec 2017 09:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Z7ebn9GrE4; Tue, 5 Dec 2017 09:35:26 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969D7127011; Tue, 5 Dec 2017 09:35:26 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB5HZP1k031848; Tue, 5 Dec 2017 12:35:25 -0500 Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) by mx0a-00196b01.pphosted.com with ESMTP id 2eks6rvy0u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Dec 2017 12:35:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n91wB0JtV8vedYKUNGxwvqK+lCNI5onOWHRZEHQQBrE=; b=oKt806k4sDPqv913wcYhUcx277JzO3+tNmbaLljQZr7ITlLX5FA9AhYrNlEjAAeht84ASAxgYUi/p8uLnx1OKz6J9mJsyM1jlfALVa155OntuWruBL2ZSR6rus1DW37naK4U1Snvzo6Fv1PqVhhxtbKKpOp4MERR2ebd0skz7Tk= Received: from CO2PR01MB1989.prod.exchangelabs.com (10.166.90.142) by CO2PR01MB1989.prod.exchangelabs.com (10.166.90.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Tue, 5 Dec 2017 17:35:19 +0000 Received: from CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) by CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) with mapi id 15.20.0282.012; Tue, 5 Dec 2017 17:35:19 +0000 From: "Mortensen, Andrew" To: "internet-drafts@ietf.org" CC: "i-d-announce@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-08.txt Thread-Index: AQHTbe8anJs4n+IaNUumkOS+lnyup6M1AvcA Date: Tue, 5 Dec 2017 17:35:19 +0000 Message-ID: References: <151249517961.23082.5298126760710075311@ietfa.amsl.com> In-Reply-To: <151249517961.23082.5298126760710075311@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:11e:1000:10:151f:25a9:7fa2:c689] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR01MB1989; 6:QTs3UtlS37NeqmgClb2An5nZdHWMmJlefqrKwDhrkDEWTxILUCknQ0utqpWFEn6TFguDEzTASrSmoppPwd4a9Hr5m1tHgWTP+BhrG4cx/A0YRWaSLXfSqtqj54NBRIkSTw8jqhDhT1CRVyR1MSwLQ4Ccd4x+pedNR9+XRkEQK8M2pBGIJwTH+u8TJbDYf6CjSBVcES9hrmSTXM28QFLSuwkDYqUVlGNf3l5nQcUu//EHBdpF6jprVNZjSLRo3+53SjjZjGSswmJxpmWDM/88h6bWupV3otLzr1xyGh0RiINUZjgp6wXCO5o6voVW21DW8WbA+aZ0gy2ujfIUGCEPh62h4BiCraDmI/AbUcku8K8=; 5:E7Fuov13WSIs1Y08sODzkwOMJC+9sTOkY83UYcz6qME8vVMTxxaSIKhhHR4TYBm5HDtVJNU6x54DY4jt+kbcXLXD4BLhV7S3WHBJFeZW8sYE4bsSo58CjbY1aIMoJhx7EU8PIveAdqZY3M+eOj7avKptjmm13rjE8DPAmuQ0cb0=; 24:TZBdnenvskUk7WX8jD2LeJ/fbxyqEC2om0jbfFejAoez0A7C1iNe1sp2knGNsYSNp2nt9Bz01CmpqzLmRAARxlSJ3ZiXyqM6UMvaNISQo2s=; 7:+C9o7FSTODVEu0o5SsA9zLctGa/kgQ1pEJYg6cWLvmiyND7qOyQ6+fsSOWcW8koKXc9rWDUHBSFM9pvXJVMow4TU7WeiTKzqTyaB+oGApttLZ+G4ZVoc3xAF0zBryG6/TcMXyQmyvbjlRwWR0uDaNnG9dZtd7JULsuo0DW8z2f36kBGXWvDjgpVvX1GwRgUafCtjWEAfjm6LOA4C3U2nBOY7d19ucQD2tnwN5X1ps7mo6tcXJITnxxo0HbMOSYoX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ee9c4d65-361d-4baf-13b8-08d53c068e55 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:CO2PR01MB1989; x-ms-traffictypediagnostic: CO2PR01MB1989: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231022)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:CO2PR01MB1989; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO2PR01MB1989; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(54534003)(24454002)(377424004)(53754006)(199004)(189003)(97736004)(76176011)(83716003)(7736002)(316002)(68736007)(2351001)(2501003)(2906002)(3280700002)(8936002)(2950100002)(3660700001)(5660300001)(33656002)(77096006)(101416001)(6486002)(4326008)(6246003)(54896002)(6916009)(53546010)(5640700003)(82746002)(53936002)(229853002)(6436002)(99286004)(6306002)(6512007)(478600001)(106356001)(81156014)(81166006)(8676002)(2900100001)(14454004)(86362001)(105586002)(54906003)(6506006)(236005)(450100002)(36756003)(25786009)(230783001)(606006)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB1989; H:CO2PR01MB1989.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E4F3F732F81E4F2595CFBD1065B458CAarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: ee9c4d65-361d-4baf-13b8-08d53c068e55 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 17:35:19.7110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB1989 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050254 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 17:35:29 -0000 --_000_E4F3F732F81E4F2595CFBD1065B458CAarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLiBUaGlzIGV4dHJlbWVseSBtaW5vciByZXZpc2lvbiBzaW1wbHkgcmVwbGFjZXMgdGhl IHRlcm0g4oCcZGVsYXnigJ0gd2l0aCDigJxyZWR1Y2UgaGVhcnRiZWF0IGZyZXF1ZW5jeeKAnSBp biBTSUctMDAzLCBwZXIgdGhlIGRpc2N1c3Npb24gaGVyZToNCg0KPGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvZG90cy9Ja09HVl9yLXRmYnhocXNtdl80SnAxUGxndTA8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJj aGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19kb3RzX0lrT0dWLTVGci0yRHRmYnhocXNtdi01RjRKcDFQ bGd1MCZkPUR3TUdhUSZjPUhsdnBycW9ucjVMdUNOOVRONjV4Tncmcj1NLTBfQ3FFVlhhOU9Rdm1K MmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJm09T3JrNTVCclNLYl82RG9qVjBibTVaaWxzTkNo dVlieFdkdlBfSDNGZVh6NCZzPWl3X0dJbWdKd2FidDk3UmRiRU1IWkpQZVV1TXVNbGgtbUxYTFJu M0ZVOGcmZT0+Pg0KDQpJdCBhbHNvIHJlbW92ZXMgdGhlIGNoYW5nZWxvZyBzZWN0aW9uIGZyb20g dGhlIGRyYWZ0LiBJdCBoYWQgZHJpZnRlZCBvdXQgb2YgZGF0ZSwgYW5kIHRoZSBHaXRIdWIgcmVw byBnaXZlcyBhIGJldHRlciBzZW5zZSBvZiB0aGUgZHJhZnQgZXZvbHV0aW9uIGFueXdheS4NCg0K YW5kcmV3DQoNCg0KDQpPbiBEZWMgNSwgMjAxNywgYXQgMTI6MzIgUE0sIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KDQpB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBE RG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxl ICAgICAgICAgICA6IERpc3RyaWJ1dGVkIERlbmlhbCBvZiBTZXJ2aWNlIChERG9TKSBPcGVuIFRo cmVhdCBTaWduYWxpbmcgUmVxdWlyZW1lbnRzDQogICAgICAgQXV0aG9ycyAgICAgICAgIDogQW5k cmV3IE1vcnRlbnNlbg0KICAgICAgICAgICAgICAgICAgICAgICAgIFJvYmVydCBNb3Nrb3dpdHoN CiAgICAgICAgICAgICAgICAgICAgICAgICBUaXJ1bWFsZXN3YXIgUmVkZHkNCkZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMDgudHh0DQpQYWdlcyAgICAgICAg ICAgOiAyMA0KRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0wNQ0KDQpBYnN0cmFjdDoNCiAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBEaXN0cmlidXRlZCBE ZW5pYWwgb2YNCiAgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RTKSBw cm90b2NvbHMgY29vcmRpbmF0aW5nDQogIGF0dGFjayByZXNwb25zZSBhZ2FpbnN0IEREb1MgYXR0 YWNrcy4NCg== --_000_E4F3F732F81E4F2595CFBD1065B458CAarbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <709417DAB107A14295AFFEF220FC54C1@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLiBUaGlzIGV4dHJlbWVs eSBtaW5vciByZXZpc2lvbiBzaW1wbHkgcmVwbGFjZXMgdGhlIHRlcm0g4oCcZGVsYXnigJ0gd2l0 aCDigJxyZWR1Y2UgaGVhcnRiZWF0IGZyZXF1ZW5jeeKAnSBpbiBTSUctMDAzLCBwZXIgdGhlIGRp c2N1c3Npb24gaGVyZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNl OnByZSI+PC9zcGFuPiZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYub3JnX2FyY2hfbXNnX2RvdHNf SWtPR1YtNUZyLTJEdGZieGhxc212LTVGNEpwMVBsZ3UwJmFtcDtkPUR3TUdhUSZhbXA7Yz1IbHZw cnFvbnI1THVDTjlUTjY1eE53JmFtcDtyPU0tMF9DcUVWWGE5T1F2bUoyZ010WEF6TDZ2NkpzWkh0 c1JrbWFSejR1ckUmYW1wO209T3JrNTVCclNLYl82RG9qVjBibTVaaWxzTkNodVlieFdkdlBfSDNG ZVh6NCZhbXA7cz1pd19HSW1nSndhYnQ5N1JkYkVNSFpKUGVVdU11TWxoLW1MWExSbjNGVThnJmFt cDtlPSIgY2xhc3M9IiI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kb3Rz L0lrT0dWX3ItdGZieGhxc212XzRKcDFQbGd1MDwvYT4mZ3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCBhbHNvIHJlbW92ZXMgdGhl IGNoYW5nZWxvZyBzZWN0aW9uIGZyb20gdGhlIGRyYWZ0LiBJdCBoYWQgZHJpZnRlZCBvdXQgb2Yg ZGF0ZSwgYW5kIHRoZSBHaXRIdWIgcmVwbyBnaXZlcyBhIGJldHRlciBzZW5zZSBvZiB0aGUgZHJh ZnQgZXZvbHV0aW9uIGFueXdheS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFuZHJldzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyA1LCAyMDE3LCBhdCAxMjozMiBQTSwgPGEgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgY2xhc3M9IiI+DQppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy48YnIgY2xhc3M9IiI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0aGUgSUVURi48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtUaXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs6IERpc3RyaWJ1dGVkIERlbmlhbCBvZiBTZXJ2aWNlIChERG9T KSBPcGVuIFRocmVhdCBTaWduYWxpbmcgUmVxdWlyZW1lbnRzPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0aG9ycyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEFuZHJldyBNb3J0ZW5zZW48YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSb2JlcnQgTW9z a293aXR6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 VGlydW1hbGVzd2FyIFJlZGR5PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1z cGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RmlsZW5hbWUgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1l bnRzLTA4LnR4dDxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5 bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPlBhZ2VzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjA8YnIgY2xhc3M9IiI+DQo8 c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bh bj5EYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzogMjAxNy0xMi0wNTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5l cyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgRGlzdHJpYnV0ZWQgRGVuaWFsIG9mPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7U2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChE T1RTKSBwcm90b2NvbHMgY29vcmRpbmF0aW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YXR0 YWNrIHJlc3BvbnNlIGFnYWluc3QgRERvUyBhdHRhY2tzLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4F3F732F81E4F2595CFBD1065B458CAarbornet_-- From nobody Tue Dec 5 16:39:45 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFAC128BBB for ; Tue, 5 Dec 2017 16:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkFD7KYbzoVI for ; Tue, 5 Dec 2017 16:39:41 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3AE128BA2 for ; Tue, 5 Dec 2017 16:39:40 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1B8EC4BCD5BE4 for ; Wed, 6 Dec 2017 00:39:37 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 6 Dec 2017 00:39:38 +0000 Received: from DGGEML509-MBX.china.huawei.com ([169.254.1.5]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 08:38:10 +0800 From: "dongyue (D)" To: "Mortensen, Andrew" CC: dots Thread-Topic: [Dots] DOTS requirement draft questions and comments Thread-Index: AdNswi4bM2GN9n2DT7qXe3+JdqRFGgBILXwAABHR9SA= Date: Wed, 6 Dec 2017 00:38:10 +0000 Message-ID: References: <00A452AB-9438-47E7-9319-6B2224CA9777@arbor.net> In-Reply-To: <00A452AB-9438-47E7-9319-6B2224CA9777@arbor.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.147.99] Content-Type: multipart/alternative; boundary="_000_B82A8EC7D625074DBD6E89645AD1D26B0127704Cdggeml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] =?utf-8?b?562U5aSNOiAgRE9UUyByZXF1aXJlbWVudCBkcmFmdCBxdWVz?= =?utf-8?q?tions_and_comments?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 00:39:44 -0000 --_000_B82A8EC7D625074DBD6E89645AD1D26B0127704Cdggeml509mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJlcGx5IQ0KDQpLaW5kIFJlZ2FyZHMsDQpZdWUNCg0K5Y+R5Lu25Lq6 OiBNb3J0ZW5zZW4sIEFuZHJldyBbbWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0XQ0K5Y+R6YCB 5pe26Ze0OiAyMDE35bm0MTLmnIg25pelIDA6MDYNCuaUtuS7tuS6ujogZG9uZ3l1ZSAoRCkgPGRv bmd5dWU2QGh1YXdlaS5jb20+DQrmioTpgIE6IGRvdHMgPGRvdHNAaWV0Zi5vcmc+DQrkuLvpopg6 IFJlOiBbRG90c10gRE9UUyByZXF1aXJlbWVudCBkcmFmdCBxdWVzdGlvbnMgYW5kIGNvbW1lbnRz DQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gU2VlIG15IHJlc3BvbnNlcyBpbmxpbmUuDQoN CmFuZHJldw0KDQoNCk9uIERlYyA0LCAyMDE3LCBhdCAxMjo0MCBBTSwgZG9uZ3l1ZSAoRCkgPGRv bmd5dWU2QGh1YXdlaS5jb208bWFpbHRvOmRvbmd5dWU2QGh1YXdlaS5jb20+PiB3cm90ZToNCg0K SGVyZSBhcmUgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzIG9uIHRoZSBkb3RzLXJlcXVpcmVtZW50 LTA3Og0KDQrigKIgICAgICAgICBTSUctMDAzOiBJdCBzYXlzIOKAmFBlZXIgRE9UUyBhZ2VudHMg U0hPVUxEIHJlZ3VsYXJseSBzZW5kIGhlYXJ0YmVhdHMgdG8gZWFjaCBvdGhlciB3aGlsZSBhIG1p dGlnYXRpb24gcmVxdWVzdCBpcyBhY3RpdmXigJkuIEJ1dCBJIHRoaW5rIHRoZSBoZWFydGJlYXRz IHNob3VsZCBiZSBzZW5kIG9uY2UgdGhlIERPVFMgc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hl ZCwgbm8gbWF0dGVyIGlmIGEgcmVxdWVzdCBpcyBhY3RpdmUgb3Igbm90Lg0KDQpUaGUgY3VycmVu dCBmb3JtIG9mIHRoaXMgcmVxdWlyZW1lbnQgaXMgdGhlIG91dGNvbWUgb2YgZGlzY3Vzc2lvbnMg Zm9sbG93aW5nIElFVEYgOTksIGluIHdoaWNoIGl0IGJlY2FtZSBhcHBhcmVudCB0aGF0IGEgemVy byBoZWFydGJlYXQgbW9kZSB3YXMgZGVzaXJhYmxlLiBQbGVhc2Ugc2VlOg0KDQo8aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk5L21hdGVyaWFscy9zbGlkZXMtOTktZG90cy1k b3RzLWhhY2thdGhvbi1yZXBvcnQvPg0KDQpTcGVjaWZpY2FsbHksIHRoZSBzbGlkZSB0aXRsZWQg 4oCcTGVzc29ucyBsZWFybmVkICgzLzMp4oCdOiDigJxaZXJvIGhlYXJ0YmVhdCBtb2RlIHNob3Vs ZCBiZSBhbGxvd2Vk4oCdLg0KDQoNCuKAoiAgICAgICAgIFNJRy0wMDM6IGl0IG1lbnRpb25lZCBp biB0aGUgc2Vjb25kIHBhcmFncmFwaCB0aGF0IOKAmCBhIERPVFMgc2VydmVyIG1pZ2h0IHdhbnQg dG8gZGVsYXkgb3IgY2Vhc2UgaGVhcnRiZWF0IGV4Y2hhbmdlcyB3aGVuIGFuIGFjdGl2ZSBET1RT IGNsaWVudCBoYXMgbm90IHJlcXVlc3RlZCBtaXRpZ2F0aW9uLCBpbiBvcmRlciB0byBjb250cm9s IGxvYWTigJkuIEZpcnN0bHksIOKAmGRlbGF54oCZIGlzIGEga2luZCBvZiB0aW1lIHNoaWZ0LCBp dCB3aWxsIG5vdCByZWR1Y2UgdGhlIGxvYWQsIEkgcmVjb21tZW5kIHRvIHJlcGxhY2Ug4oCYZGVs YXnigJkgd2l0aCDigJhyZWR1Y2UgdGhlIGhlYXJ0YmVhdCBmcmVxdWVuY3nigJkgb3Ig4oCYaW5j cmVhc2UgdGhlIGhlYXJ0YmVhdCBpbnRlcnZhbOKAmS4NCg0KV2UgY2FuIHJlcGxhY2UgdGhlIOKA nGRlbGF54oCdIHRlcm0uDQoNCg0KDQoNClNlY29uZGx5LCBJIGFtIG5vdCBjbGVhciB3aHkgRE9U UyBzZXJ2ZXIgd2FudCB0byBjZWFzZSBoZWFydGJlYXQ/IEluIHRoaXMgY2FzZSwgaWYgdGhlIGhl YXJ0YmVhdCBoYXMgYmVlbiBjZWFzZWQsIHRoZSBtaXRpZ2F0aW9uIHdpbGwgYmUgYXV0b21hdGlj YWxseSB0cmlnZ2VyZWQhDQoNClRyaWdnZXJpbmcgbWl0aWdhdGlvbiBvbiBsb3NzIG9mIGhlYXJ0 YmVhdCBpcyBvbmUgcG9zc2libGUgbW9kZSBvZiBkZXBsb3ltZW50LiBJdCBpcyBub3QgdGhlIG9u bHkgbWVjaGFuaXNtIGZvciByZXF1ZXN0aW5nIG1pdGlnYXRpb24uIEF0IGxlYXN0IGFzIGRlc2Ny aWJlZCBpbiB0aGUgRE9UUyBhcmNoaXRlY3R1cmUsIGl0J3MgYWxzbyBiYXNlZCBvbiB0aGUgbG9z cyBvZiBoZWFydGJlYXQgZnJvbSB0aGUgY2xpZW50LCBub3QgdGhlIHNlcnZlci4NCg0KDQrigKIg ICAgICAgICBTRUMtMDA0OiBJbiB0aGUgZmlyc3QgcGFyYWdyYXBoLCB0aGUgc3RhdHVzIGlzIG5v dCBhIG1lc3NhZ2UgZnJvbSBET1RTIGNsaWVudCwgSSByZWNvbW1lbmQgaXQgdG8gYmUg4oCYc3Rh dHVzIHJlcXVlc3TigJkNCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgY2hhbmdlIGltcHJvdmVzIHRo ZSBjbGFyaXR5IG9mIHRoYXQgcGFyYWdyYXBoLiBDb21wYXJlIHRoZSBjdXJyZW50IGZvcm06DQoN CuKAnERPVFMgc2VydmVycyBNVVNUIGF1dGhvcml6ZSBhbGwgbWVzc2FnZXMgZnJvbSBET1RTIGNs aWVudHMgd2hpY2ggcGVydGFpbiB0b+KApnN0YXR1cy7igJ0NCg0Kd2l0aCB0aGUgY2hhbmdlIHlv deKAmXJlIHByb3Bvc2luZzoNCg0K4oCcRE9UUyBzZXJ2ZXJzIE1VU1QgYXV0aG9yaXplIGFsbCBt ZXNzYWdlcyBmcm9tIERPVFMgY2xpZW50cyB3aGljaCBwZXJ0YWluIHRv4oCmc3RhdHVzIHJlcXVl c3RzLuKAnQ0KDQpUbyBtZSwgdGhlIGNoYW5nZSBoYXMgdGhlIGVmZmVjdCBvZiByZXF1aXJpbmcg YXV0aG9yaXphdGlvbiBvZiBhbGwgbWVzc2FnZXMgKmFib3V0KiBzdGF0dXMgcmVxdWVzdHMsIGFz IG9wcG9zZWQgdG8gbWVzc2FnZXMgYWJvdXQgc3RhdHVzLg0KDQo= --_000_B82A8EC7D625074DBD6E89645AD1D26B0127704Cdggeml509mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91 ciByZXBseSENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+S2lu ZCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBNb3J0ZW5zZW4sDQogQW5kcmV3IFttYWlsdG86YW1v cnRlbnNlbkBhcmJvci5uZXRdIDxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7lj5HpgIHml7bp l7Q8L3NwYW4+OjwvYj4gMjAxNzxzcGFuIGxhbmc9IlpILUNOIj7lubQ8L3NwYW4+MTI8c3BhbiBs YW5nPSJaSC1DTiI+5pyIPC9zcGFuPjY8c3BhbiBsYW5nPSJaSC1DTiI+5pelPC9zcGFuPiAwOjA2 PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj46PC9iPiBkb25neXVl IChEKSAmbHQ7ZG9uZ3l1ZTZAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1D TiI+5oqE6YCBPC9zcGFuPjo8L2I+IGRvdHMgJmx0O2RvdHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ PHNwYW4gbGFuZz0iWkgtQ04iPuS4u+mimDwvc3Bhbj46PC9iPiBSZTogW0RvdHNdIERPVFMgcmVx dWlyZW1lbnQgZHJhZnQgcXVlc3Rpb25zIGFuZCBjb21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gU2Vl IG15IHJlc3BvbnNlcyBpbmxpbmUuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YW5kcmV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIERlYyA0LCAyMDE3LCBhdCAxMjo0MCBBTSwgZG9uZ3l1ZSAo RCkgJmx0OzxhIGhyZWY9Im1haWx0bzpkb25neXVlNkBodWF3ZWkuY29tIj5kb25neXVlNkBodWF3 ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhlcmUgYXJlIGEgZmV3IHF1ZXN0aW9ucy9jb21t ZW50cyBvbiB0aGUgZG90cy1yZXF1aXJlbWVudC0wNzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TSUctMDAzOg0KIEl0IHNh eXMg4oCYUGVlciBET1RTIGFnZW50cyBTSE9VTEQgcmVndWxhcmx5IHNlbmQgaGVhcnRiZWF0cyB0 byBlYWNoIG90aGVyIHdoaWxlIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFjdGl2ZeKAmS4gQnV0 IEkgdGhpbmsgdGhlIGhlYXJ0YmVhdHMgc2hvdWxkIGJlIHNlbmQgb25jZSB0aGUgRE9UUyBzZXNz aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLCBubyBtYXR0ZXIgaWYgYSByZXF1ZXN0IGlzIGFjdGl2 ZSBvciBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IGZvcm0gb2Yg dGhpcyByZXF1aXJlbWVudCBpcyB0aGUgb3V0Y29tZSBvZiBkaXNjdXNzaW9ucyBmb2xsb3dpbmcg SUVURiA5OSwgaW4gd2hpY2ggaXQgYmVjYW1lIGFwcGFyZW50IHRoYXQgYSB6ZXJvIGhlYXJ0YmVh dCBtb2RlIHdhcyBkZXNpcmFibGUuIFBsZWFzZSBzZWU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTkvbWF0ZXJpYWxzL3NsaWRlcy05OS1kb3RzLWRvdHMt aGFja2F0aG9uLXJlcG9ydC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85 OS9tYXRlcmlhbHMvc2xpZGVzLTk5LWRvdHMtZG90cy1oYWNrYXRob24tcmVwb3J0LzwvYT4mZ3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNw ZWNpZmljYWxseSwgdGhlIHNsaWRlIHRpdGxlZCDigJxMZXNzb25zIGxlYXJuZWQgKDMvMynigJ06 IOKAnFplcm8gaGVhcnRiZWF0IG1vZGUgc2hvdWxkIGJlIGFsbG93ZWTigJ0uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ U0lHLTAwMzoNCiBpdCBtZW50aW9uZWQgaW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggdGhhdCDigJgg YSBET1RTIHNlcnZlciBtaWdodCB3YW50IHRvIGRlbGF5IG9yIGNlYXNlIGhlYXJ0YmVhdCBleGNo YW5nZXMgd2hlbiBhbiBhY3RpdmUgRE9UUyBjbGllbnQgaGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdh dGlvbiwgaW4gb3JkZXIgdG8gY29udHJvbCBsb2Fk4oCZLiBGaXJzdGx5LCDigJhkZWxheeKAmSBp cyBhIGtpbmQgb2YgdGltZSBzaGlmdCwgaXQgd2lsbCBub3QgcmVkdWNlIHRoZQ0KIGxvYWQsIEkg cmVjb21tZW5kIHRvIHJlcGxhY2Ug4oCYZGVsYXnigJkgd2l0aCDigJhyZWR1Y2UgdGhlIGhlYXJ0 YmVhdCBmcmVxdWVuY3nigJkgb3Ig4oCYaW5jcmVhc2UgdGhlIGhlYXJ0YmVhdCBpbnRlcnZhbOKA mS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNhbiByZXBsYWNlIHRoZSDigJxkZWxheeKAnSB0ZXJt LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5TZWNvbmRseSwgSSBhbSBub3QgY2xlYXIgd2h5IERPVFMgc2VydmVyIHdhbnQg dG8gY2Vhc2UgaGVhcnRiZWF0PyBJbiB0aGlzIGNhc2UsIGlmIHRoZSBoZWFydGJlYXQgaGFzIGJl ZW4gY2Vhc2VkLCB0aGUgbWl0aWdhdGlvbiB3aWxsIGJlIGF1dG9tYXRpY2FsbHkNCiB0cmlnZ2Vy ZWQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcmlnZ2VyaW5nIG1pdGlnYXRpb24gb24gbG9zcyBvZiBo ZWFydGJlYXQgaXMgb25lIHBvc3NpYmxlIG1vZGUgb2YgZGVwbG95bWVudC4gSXQgaXMgbm90IHRo ZSBvbmx5IG1lY2hhbmlzbSBmb3IgcmVxdWVzdGluZyBtaXRpZ2F0aW9uLiBBdCBsZWFzdCBhcyBk ZXNjcmliZWQgaW4gdGhlIERPVFMgYXJjaGl0ZWN0dXJlLCBpdCdzIGFsc28gYmFzZWQgb24gdGhl IGxvc3Mgb2YgaGVhcnRiZWF0IGZyb20gdGhlIGNsaWVudCwNCiBub3QgdGhlIHNlcnZlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5TRUMtMDA0Og0KIEluIHRoZSBmaXJzdCBwYXJhZ3JhcGgsIHRoZSBzdGF0dXMgaXMgbm90IGEg bWVzc2FnZSBmcm9tIERPVFMgY2xpZW50LCBJIHJlY29tbWVuZCBpdCB0byBiZSDigJhzdGF0dXMg cmVxdWVzdOKAmTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayB0aGF0IGNoYW5n ZSBpbXByb3ZlcyB0aGUgY2xhcml0eSBvZiB0aGF0IHBhcmFncmFwaC4gQ29tcGFyZSB0aGUgY3Vy cmVudCBmb3JtOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7igJxET1RTIHNlcnZlcnMgTVVTVCBhdXRob3JpemUgYWxsIG1lc3NhZ2VzIGZyb20g RE9UUyBjbGllbnRzIHdoaWNoIHBlcnRhaW4gdG/igKZzdGF0dXMu4oCdPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGggdGhlIGNoYW5nZSB5 b3XigJlyZSBwcm9wb3Npbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPuKAnERPVFMgc2VydmVycyBNVVNUIGF1dGhvcml6ZSBhbGwgbWVzc2Fn ZXMgZnJvbSBET1RTIGNsaWVudHMgd2hpY2ggcGVydGFpbiB0b+KApnN0YXR1cyByZXF1ZXN0cy7i gJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VG8gbWUsIHRoZSBjaGFuZ2UgaGFzIHRoZSBlZmZlY3Qgb2YgcmVxdWlyaW5nIGF1dGhvcml6YXRp b24gb2YgYWxsIG1lc3NhZ2VzICphYm91dCogc3RhdHVzIHJlcXVlc3RzLCBhcyBvcHBvc2VkIHRv IG1lc3NhZ2VzIGFib3V0IHN0YXR1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B82A8EC7D625074DBD6E89645AD1D26B0127704Cdggeml509mbxchi_-- From nobody Wed Dec 6 04:30:53 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50273126C22; Wed, 6 Dec 2017 04:30:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151256345229.30707.5123997227751613557@ietfa.amsl.com> Date: Wed, 06 Dec 2017 04:30:52 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 12:30:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-11.txt Pages : 74 Date : 2017-12-06 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX o This RFC Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 6 04:39:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0521271FD for ; Wed, 6 Dec 2017 04:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZFk1-a-Zo_m for ; Wed, 6 Dec 2017 04:39:30 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FE0124D6C for ; Wed, 6 Dec 2017 04:39:29 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id A769D40AEB for ; Wed, 6 Dec 2017 13:39:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 8CF851C0080 for ; Wed, 6 Dec 2017 13:39:28 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 13:39:28 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt Thread-Index: AQHTbo4RjIek+rwmy0iotdULJbLws6M2Px/w Date: Wed, 6 Dec 2017 12:39:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A086F60@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151256345229.30707.5123997227751613557@ietfa.amsl.com> In-Reply-To: <151256345229.30707.5123997227751613557@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 12:39:32 -0000 Hi all,=20 The changes in the new version are as follows:=20 - add conflict-scope - clarify the usage of retry-timer - merge the two YANG modules in a single one - clarify the behavior when a request is received with a lifetime set to 0 - clarify that multiple mitigations are not allowed in a single PUT - As for assigning 4646 as a strongly recommended port number - some text reordering, edits, and fixing nits We don't have any pending issue in our list.=20 Please review and comment.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 6 d=E9cembre 2017 13:31 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-11.txt > Pages : 74 > Date : 2017-12-06 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-11 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 6 07:36:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B1C126D45; Wed, 6 Dec 2017 07:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOpDBocilh18; Wed, 6 Dec 2017 07:36:18 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049C7126DD9; Wed, 6 Dec 2017 07:36:18 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 7F243120DB7; Wed, 6 Dec 2017 16:36:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 5E6CE16005E; Wed, 6 Dec 2017 16:36:16 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 16:36:16 +0100 From: To: "dots-chairs@ietf.org" CC: "dots@ietf.org" Thread-Topic: RFC7120-Early Allocation: Request for an early allocation of a service port Thread-Index: AdNup+82Fx0Hn7RHT1WkOUagx/xIHg== Date: Wed, 6 Dec 2017 15:36:15 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08713E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A08713EOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] RFC7120-Early Allocation: Request for an early allocation of a service port X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:36:20 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A08713EOPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi chairs, Given that the signal channel specification is almost stable and many imple= mentations are disclosed, I'm sending this request following the procedure = in Section 3 of RFC7120 to ask for an early allocation of a port number for= the signal channel. This early allocation will ease interoperability. More information about this early allocation request is provided below: The early allocated port number is to be assigned to the DOTS signal channel protocol for both UDP and TCP from the "Service Name and Transport Protocol Port Number Registry" available at https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml. We suggest that the port number 4646 is to be assigned. 4646 is the ASCII decimal value for ".." (DOTS). Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A08713EOPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi chairs,

 <= /p>

Given that the signal cha= nnel specification is almost stable and many implementations are disclosed,= I’m sending this request following the procedure in Section 3 of RFC7120 to ask for an early allocation of a port number for the signa= l channel. This early allocation will ease interoperability.

 <= /p>

More information about th= is early allocation request is provided below:

 <= /p> 

   The early allocated port number is t=
o be assigned to the DOTS signal
   channel protocol for both UDP and TC=
P from the "Service Name and
   Transport Protocol Port Number Regis=
try" available at
   https://www.iana.org/assignments/service-names-port-n=
umbers/service-
   names-port-numbers.xhtml.
 
   We suggest that the port number 4646=
 is to be assigned.
   4646 is the ASCII decimal value for =
".." (DOTS).

 <= /p>

Thank you.

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 <= /p>

--_000_787AE7BB302AE849A7480A190F8B93300A08713EOPEXCLILMA3corp_-- From nobody Wed Dec 6 09:43:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E6C1272E1 for ; Wed, 6 Dec 2017 09:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze3tu39nxrw1 for ; Wed, 6 Dec 2017 09:43:53 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2C91275F4 for ; Wed, 6 Dec 2017 09:43:52 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB6HhpP4005153; Wed, 6 Dec 2017 12:43:51 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vB6HhpP4005153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1512582231; bh=wB6wqEKRTxplX9Yb6sv6UsA+GHf0I9IC56uLCqIx5Ss=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=KC7xkNhYbox1PxD5l2DwVsydmT+o5drzwVbZBtYWRl645As3yBA7+YJ2J7eP6Uf1A Hd85e+ATRigjDIs1ne2KzQ9Pu8p/jSEVB7uzSKEVEQv+ZxygfKiNh3wqLdM+m067Rz MkpRX8PPRlfHul5ASvggbpYkneLGfolpFR8clDnA= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB6HhlgJ009257; Wed, 6 Dec 2017 12:43:47 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 12:43:47 -0500 From: Roman Danyliw To: "mohamed.boucadair@orange.com" CC: "dots@ietf.org" Thread-Topic: RFC7120-Early Allocation: Request for an early allocation of a service port Thread-Index: AdNup+82Fx0Hn7RHT1WkOUagx/xIHgAEZU9A Date: Wed, 6 Dec 2017 17:43:46 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC013134043D@marathon> References: <787AE7BB302AE849A7480A190F8B93300A08713E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A08713E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC013134043Dmarathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] RFC7120-Early Allocation: Request for an early allocation of a service port X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 17:43:56 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC013134043Dmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Med! This message is being sent to acknowledge receipt of your request. The cha= irs will discuss and get back to you shortly. Regards, Roman and Tobias From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, December 06, 2017 10:36 AM To: dots-chairs@ietf.org Cc: dots@ietf.org Subject: [Dots] RFC7120-Early Allocation: Request for an early allocation o= f a service port Hi chairs, Given that the signal channel specification is almost stable and many imple= mentations are disclosed, I'm sending this request following the procedure = in Section 3 of RFC7120 to ask for an early allocation of a port number for= the signal channel. This early allocation will ease interoperability. More information about this early allocation request is provided below: The early allocated port number is to be assigned to the DOTS signal channel protocol for both UDP and TCP from the "Service Name and Transport Protocol Port Number Registry" available at https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml. We suggest that the port number 4646 is to be assigned. 4646 is the ASCII decimal value for ".." (DOTS). Thank you. Cheers, Med --_000_359EC4B99E040048A7131E0F4E113AFC013134043Dmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Med!<= /span>

 

This message is being = sent to acknowledge receipt of your request.  The chairs will discuss = and get back to you shortly.

 

Regards,

Roman and Tobias<= /o:p>

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, December 06, 2017 10:36 AM
To: dots-chairs@ietf.org
Cc: dots@ietf.org
Subject: [Dots] RFC7120-Early Allocation: Request for an early alloc= ation of a service port

 

Hi chairs,

 

Given that the signal channel specification is almost stab= le and many implementations are disclosed, I’m sending this request f= ollowing the procedure in Section 3 of RFC7120 to ask for an early allocation of a port number for the signal channel. This earl= y allocation will ease interoperability.

 

More information about this early allocation request is pr= ovided below:

 

   The early allocated port number is to be assigned to the =
DOTS signal
   channel protocol for both UDP and TCP from the "Serv=
ice Name and
   Transport Protocol Port Number Registry" available a=
t
   https://www.iana.org/assignments/service-names-port-numbers/ser=
vice-
   names-port-numbers.xhtml.
 
   We suggest that the port number 4646 is to be assigned.
   4646 is the ASCII decimal value for ".." (DOTS).

 

Thank you.

 

Cheers,

Med

 

 

 

--_000_359EC4B99E040048A7131E0F4E113AFC013134043Dmarathon_-- From nobody Wed Dec 6 09:50:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842AD1241F5 for ; Wed, 6 Dec 2017 09:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1mIEZoGw5cn for ; Wed, 6 Dec 2017 09:50:55 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2653126D85 for ; Wed, 6 Dec 2017 09:50:54 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eMdqN-0003pF-Uq; Wed, 06 Dec 2017 17:50:52 +0000 From: "Jon Shallow" To: , References: <151256345229.30707.5123997227751613557@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A086F60@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A086F60@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 6 Dec 2017 17:50:53 -0000 Message-ID: <052a01d36eba$c2e13d70$48a3b850$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQMYVWiR8pMFLffP5uhW32BsP4x40gH5X3tsoJz5nFA= Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 17:50:56 -0000 Hi Med, Some minor things on a quick scan through. 4.5.2 ack_timeout needs correcting to ack-timeout 5.2 - exchanegd needs correcting to exchanged 7.1 additionaly needs correcting to additionally 9.4 structrue needs correcting to structure 9.4.1 target_ip needs correcting to target-ip for consistency 9.4.2 There is inconsistence in the naming format of the Parameter Name: with ", not ", with space, not space (and should we be using upper-case = in parameters such as MinValue?) conflict-scope is not in the CBOR Mappings in Table 4. Can I ask that = it be put at the end of the table, so not messing up interoperability between = DOTS Clients/Servers based on different draft versions? Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 06 December 2017 12:39 To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt Hi all,=20 The changes in the new version are as follows:=20 - add conflict-scope - clarify the usage of retry-timer - merge the two YANG modules in a single one - clarify the behavior when a request is received with a lifetime set to = 0 - clarify that multiple mitigations are not allowed in a single PUT - As for assigning 4646 as a strongly recommended port number - some text reordering, edits, and fixing nits We don't have any pending issue in our list.=20 Please review and comment.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet-=20 > drafts@ietf.org Envoy=E9=A0: mercredi 6 d=E9cembre 2017 13:31 =C0=A0:=20 > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action:=20 > draft-ietf-dots-signal-channel-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the=20 > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-11.txt > Pages : 74 > Date : 2017-12-06 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned = to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > 1 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 7 00:54:32 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41564129353 for ; Thu, 7 Dec 2017 00:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdIIa1N_h9QA for ; Thu, 7 Dec 2017 00:54:28 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFBC1200C1 for ; Thu, 7 Dec 2017 00:54:27 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 315F9100D92; Thu, 7 Dec 2017 09:54:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 11347180075; Thu, 7 Dec 2017 09:54:26 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0361.001; Thu, 7 Dec 2017 09:54:25 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt Thread-Index: AQMYVWiR8pMFLffP5uhW32BsP4x40gH5X3tsoJz5nFCAAPzMkA== Date: Thu, 7 Dec 2017 08:54:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08FB40@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151256345229.30707.5123997227751613557@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A086F60@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <052a01d36eba$c2e13d70$48a3b850$@jpshallow.com> In-Reply-To: <052a01d36eba$c2e13d70$48a3b850$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 08:54:30 -0000 Hi Jon,=20 Thank you for reviewing.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 6 d=E9cembre 2017 18:51 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt >=20 > Hi Med, >=20 > Some minor things on a quick scan through. >=20 > 4.5.2 ack_timeout needs correcting to ack-timeout >=20 > 5.2 - exchanegd needs correcting to exchanged >=20 > 7.1 additionaly needs correcting to additionally >=20 > 9.4 structrue needs correcting to structure >=20 > 9.4.1 target_ip needs correcting to target-ip for consistency >=20 [Med] All fixed.=20 > 9.4.2 There is inconsistence in the naming format of the Parameter Name: > with ", not ", with space, not space (and should we be using upper-case i= n > parameters such as MinValue?) [Med] Agree. Fixed. >=20 > conflict-scope is not in the CBOR Mappings in Table 4. Can I ask that it > be > put at the end of the table, so not messing up interoperability between > DOTS > Clients/Servers based on different draft versions? >=20 [Med] Happily. A new version with these fixes will be online soon.=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > ietf-supjps-mohamed.boucadair@orange.com > Sent: 06 December 2017 12:39 > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-11.txt >=20 > Hi all, >=20 > The changes in the new version are as follows: > - add conflict-scope > - clarify the usage of retry-timer > - merge the two YANG modules in a single one > - clarify the behavior when a request is received with a lifetime set to = 0 > - clarify that multiple mitigations are not allowed in a single PUT > - As for assigning 4646 as a strongly recommended port number > - some text reordering, edits, and fixing nits >=20 > We don't have any pending issue in our list. >=20 > Please review and comment. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org Envoy=E9=A0: mercredi 6 d=E9cembre 2017 13:31 =C0=A0: > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Action: > > draft-ietf-dots-signal-channel-11.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the > > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-11.txt > > Pages : 74 > > Date : 2017-12-06 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > o This RFC > > > > Please update TBD statements with the port number to be assigned to > > DOTS Signal Channel Protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-11 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > > 1 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-11 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 7 02:43:32 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E7412726E; Thu, 7 Dec 2017 02:43:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151264340529.31216.9533942192573068497@ietfa.amsl.com> Date: Thu, 07 Dec 2017 02:43:25 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-12.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 10:43:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-12.txt Pages : 74 Date : 2017-12-07 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX o This RFC Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 7 02:46:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17551293F4 for ; Thu, 7 Dec 2017 02:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtPsavG9z1Ny for ; Thu, 7 Dec 2017 02:46:13 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE461293F2 for ; Thu, 7 Dec 2017 02:46:12 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 44D60100E26 for ; Thu, 7 Dec 2017 11:46:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 2D39440094 for ; Thu, 7 Dec 2017 11:46:11 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Thu, 7 Dec 2017 11:46:10 +0100 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-signal-channel-12.txt Thread-Index: AQHTb0g/H70PvddYQUyryFMrCZG37aM3sg1Q Date: Thu, 7 Dec 2017 10:46:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A091BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151264340529.31216.9533942192573068497@ietfa.amsl.com> In-Reply-To: <151264340529.31216.9533942192573068497@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-12.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 10:46:15 -0000 Re-, This version fixes the nits identified by Jon.=20 The YANG module is updated to return references to ACLs when a conflict is = because of a whitelist.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: jeudi 7 d=E9cembre 2017 11:43 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-signal-channel-12.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-12.txt > Pages : 74 > Date : 2017-12-07 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-12 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-12 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Dec 7 12:50:59 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90988127B57 for ; Thu, 7 Dec 2017 12:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlgHAwdp9rke for ; Thu, 7 Dec 2017 12:50:56 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B43126BF0 for ; Thu, 7 Dec 2017 12:50:54 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB7Korem018181 for ; Thu, 7 Dec 2017 15:50:53 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vB7Korem018181 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1512679853; bh=4l9RdMbep+PtT7LSCiCF6goweqXGauNDM0EW+ZcaUog=; h=From:To:Subject:Date:From; b=fdQH/SNsYPemp4KrnNWvz46OAOxklrvU17i3AF+o4hd09NQj/CDUPPppyjMJhBjdF VCFEIkxRVuAnV3hWEgIeNnOdOuGFFDpgVCTztJNHfLWxmYMepPH0X3JhYs0/acbMUM L62apQ2g7z26G25y0ZmCGRuDOiak89K2GbNyuN0E= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB7KomZS024139 for ; Thu, 7 Dec 2017 15:50:48 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Thu, 7 Dec 2017 15:50:48 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: WGLC on DOTS Requirements Thread-Index: AdNvm/lDz0QLqz1aR/uWENfjoLPoNQ== Date: Thu, 7 Dec 2017 20:50:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:50:58 -0000 Hello! Consistent with our discussion at the Singapore meeting and with the concur= rence of the draft authors, we are starting a working group last call (WGLC= ) for the DOTS Requirements draft: Distributed Denial of Service (DDoS) Open Threat Signaling Requirements draft-ietf-dots-requirements-08 https://tools.ietf.org/html/draft-ietf-dots-requirements-08 Please send all comments to the DOTS mailing list. This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-c= alendar year vacations). Thanks, Roman From nobody Thu Dec 7 23:35:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62812711D for ; Thu, 7 Dec 2017 23:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiZ9bY7-W_aQ for ; Thu, 7 Dec 2017 23:35:34 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABA7126C2F for ; Thu, 7 Dec 2017 23:35:34 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C14C3ED03941B for ; Fri, 8 Dec 2017 07:35:30 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 8 Dec 2017 07:35:32 +0000 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.252]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 15:35:27 +0800 From: "Xialiang (Frank)" To: Roman Danyliw CC: "dots@ietf.org" Thread-Topic: WGLC on DOTS Requirements Thread-Index: AdNvm/lDz0QLqz1aR/uWENfjoLPoNQAWpoHQ Date: Fri, 8 Dec 2017 07:35:26 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] =?gb2312?b?tPC4tDogV0dMQyBvbiBET1RTIFJlcXVpcmVtZW50cw==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 07:35:36 -0000 U3VwcG9ydCENClRoZSBkcmFmdCBpcyBnb29kIGVub3VnaCBhbmQgaGFzIG5vIGlzc3VlcyB0byBi ZSBhZGRyZXNzZWQsIElNTy4NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IERvdHMgW21h aWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9tYW4gRGFueWxpdw0Kt6LLzcqxvOQ6 IDIwMTfE6jEy1MI4yNUgNDo1MQ0KytW8/sjLOiBkb3RzQGlldGYub3JnDQrW98ziOiBbRG90c10g V0dMQyBvbiBET1RTIFJlcXVpcmVtZW50cw0KDQpIZWxsbyENCg0KQ29uc2lzdGVudCB3aXRoIG91 ciBkaXNjdXNzaW9uIGF0IHRoZSBTaW5nYXBvcmUgbWVldGluZyBhbmQgd2l0aCB0aGUgY29uY3Vy cmVuY2Ugb2YgdGhlIGRyYWZ0IGF1dGhvcnMsIHdlIGFyZSBzdGFydGluZyBhIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIChXR0xDKSBmb3IgdGhlIERPVFMgUmVxdWlyZW1lbnRzIGRyYWZ0Og0KDQpE aXN0cmlidXRlZCBEZW5pYWwgb2YgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5n IFJlcXVpcmVtZW50cw0KZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wOA0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMDgNCg0KUGxl YXNlIHNlbmQgYWxsIGNvbW1lbnRzIHRvIHRoZSBET1RTIG1haWxpbmcgbGlzdC4NCg0KVGhpcyBX R0xDIHdpbGwgZW5kIG9uIEphbnVhcnkgMiwgMjAxOCAofjMgd2Vla3MgdG8gYWNjb3VudCBmb3Ig ZW5kLW9mLXRoZS1jYWxlbmRhciB5ZWFyIHZhY2F0aW9ucykuDQoNClRoYW5rcywNClJvbWFuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1h aWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kb3RzDQo= From nobody Fri Dec 8 01:41:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEA81200CF for ; Fri, 8 Dec 2017 01:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEdegoIR0mm4 for ; Fri, 8 Dec 2017 01:41:01 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAE3126579 for ; Fri, 8 Dec 2017 01:41:01 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id B1E8F40D49; Fri, 8 Dec 2017 10:40:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 9AA3B1C008A; Fri, 8 Dec 2017 10:40:59 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 10:40:59 +0100 From: To: Roman Danyliw , "dots@ietf.org" Thread-Topic: WGLC on DOTS Requirements Thread-Index: AdNvm/lDz0QLqz1aR/uWENfjoLPoNQAam2rw Date: Fri, 8 Dec 2017 09:40:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0950AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 09:41:03 -0000 Hi all,=20 I support this document to be advanced in the publication process. I have the following comments: =20 - Align the text with the outcome of recent discussions: for example, suppl= ying a lifetime is a MUST. - Add some text about the expected behavior of client-side DOTS gateways to= prevent leaking privacy information + server-side DOTS gateways to help se= rvers to enforce policies. - Add some text about resolution libraries at DOTS servers to handle reques= ts having FQDN/URIs as mitigation scope.=20 - Update DM versioning requirement; no need to mention the text about versi= on 1. The detailed comments and other easy-to-fix nits are available at: https://= github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-dots-requir= ements-08-rev%20Med.pdf =20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw > Envoy=E9=A0: jeudi 7 d=E9cembre 2017 21:51 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the Singapore meeting and with the > concurrence of the draft authors, we are starting a working group last > call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >=20 > Please send all comments to the DOTS mailing list. >=20 > This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the= - > calendar year vacations). >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 8 07:09:13 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124C0124D68; Fri, 8 Dec 2017 07:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l3sEv4wWRak; Fri, 8 Dec 2017 07:09:09 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45B31243FE; Fri, 8 Dec 2017 07:09:09 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB8F91Ef040505; Fri, 8 Dec 2017 10:09:01 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu vB8F91Ef040505 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1512745741; bh=zOd/CboLV8rNlZk5N7BBtK+pLgS/hwi6AtlRYclXuRw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=jgZYH9vnydBhnpxngsq9U9FmAvYDKwjg9iA3jJFL22dcnVsAZFUuokihxgCXOAPHy qpIixY6sSRgER4rcoywI5CkKEpUuTGTv5pQz4dWZIH7BUVt8eGKqvrDlwJiVDsnUFN dpd+u7xBpRs1Npo00Wqg2y10XZbfSkeembTl6nws= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB8F8wOX021965; Fri, 8 Dec 2017 10:08:58 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 10:08:57 -0500 From: Roman Danyliw To: "mohamed.boucadair@orange.com" CC: "dots@ietf.org" , "dots-chairs@ietf.org" Thread-Topic: RFC7120-Early Allocation: Request for an early allocation of a service port Thread-Index: AdNup+82Fx0Hn7RHT1WkOUagx/xIHgBi/mqQ Date: Fri, 8 Dec 2017 15:08:57 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131341B71@marathon> References: <787AE7BB302AE849A7480A190F8B93300A08713E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A08713E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0131341B71marathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] RFC7120-Early Allocation: Request for an early allocation of a service port X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:09:12 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC0131341B71marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Med! The conditions per Section 2 of RFC7120 for early allocation are met with t= he current draft and implementation momentum. No judgement is rendered on = the specific port number recommendation. Next, per step (3) of Section 3.1 of RFC7120, we need an assessment on whet= her there is consensus from the WG on that allocation. That consensus call= will be started in a different thread. Regards, Roman From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, December 06, 2017 10:36 AM To: dots-chairs@ietf.org Cc: dots@ietf.org Subject: [Dots] RFC7120-Early Allocation: Request for an early allocation o= f a service port Hi chairs, Given that the signal channel specification is almost stable and many imple= mentations are disclosed, I'm sending this request following the procedure = in Section 3 of RFC7120 to ask for an early allocation of a port number for= the signal channel. This early allocation will ease interoperability. More information about this early allocation request is provided below: The early allocated port number is to be assigned to the DOTS signal channel protocol for both UDP and TCP from the "Service Name and Transport Protocol Port Number Registry" available at https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml. We suggest that the port number 4646 is to be assigned. 4646 is the ASCII decimal value for ".." (DOTS). Thank you. Cheers, Med --_000_359EC4B99E040048A7131E0F4E113AFC0131341B71marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med!

 

The conditions per Sec= tion 2 of RFC7120 for early allocation are met with the current draft and i= mplementation momentum.  No judgement is rendered on the specific port= number recommendation.

 

Next, per step (3) of = Section 3.1 of RFC7120, we need an assessment on whether there is consensus= from the WG on that allocation.  That consensus call will be started = in a different thread.

 

Regards,

Roman

 

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, December 06, 2017 10:36 AM
To: dots-chairs@ietf.org
Cc: dots@ietf.org
Subject: [Dots] RFC7120-Early Allocation: Request for an early alloc= ation of a service port

 

Hi chairs,

 

Given that the signal channel specification is almost stab= le and many implementations are disclosed, I’m sending this request f= ollowing the procedure in Section 3 of RFC7120 to ask for an early allocation of a port number for the signal channel. This earl= y allocation will ease interoperability.

 

More information about this early allocation request is pr= ovided below:

 

   The early allocated port number is to be assigned to the =
DOTS signal
   channel protocol for both UDP and TCP from the "Serv=
ice Name and
   Transport Protocol Port Number Registry" available a=
t
   https://www.iana.org/assignments/service-names-port-numbers/ser=
vice-
   names-port-numbers.xhtml.
 
   We suggest that the port number 4646 is to be assigned.
   4646 is the ASCII decimal value for ".." (DOTS).

 

Thank you.

 

Cheers,

Med

 

 

 

--_000_359EC4B99E040048A7131E0F4E113AFC0131341B71marathon_-- From nobody Fri Dec 8 07:27:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7FE1243F6 for ; Fri, 8 Dec 2017 07:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvj3Mj0UgKsO for ; Fri, 8 Dec 2017 07:27:01 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBBD120721 for ; Fri, 8 Dec 2017 07:27:01 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB8FR0JW023555 for ; Fri, 8 Dec 2017 10:27:00 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vB8FR0JW023555 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1512746820; bh=A+Jz4/XUQu/JngRf3/kv4xNcvwvzKEmU0PhX8TGtE8c=; h=From:To:Subject:Date:From; b=bEzaxnAhU1fM1/XXi6czBcmqkUSeea9vuxTtbqAZgjF7YhKr0Nx0McjWEIa0TGI+L Yn4sbYGTW2YzXDs+15brKob+7kqxvVHMP/sWshABY+8olAivYJfLsrPG5DA53XXEg+ z41+dDj2plRLmAHtWKP8IesKOYXwnGwTpQeLxDhU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vB8FQtwr026703 for ; Fri, 8 Dec 2017 10:26:55 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 10:26:54 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Consensus call for early port allocation Thread-Index: AdNwNhVMEAJ7dCaQQ5e1tQiY+SmmtQ== Date: Fri, 8 Dec 2017 15:26:54 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Consensus call for early port allocation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:27:03 -0000 Hello WG! The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) have = requested an early allocation of a port number from IANA per RFC7120. See = https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. To proceed, WG consensus on this allocation is required (per step 3 of Sect= ion 3.1 of RFC7120). Please provide feedback on the mailing list on this t= opic by Friday, December 15. Regards, Roman and Tobias From nobody Fri Dec 8 07:41:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCBB126D74 for ; Fri, 8 Dec 2017 07:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDiXRd6C1Iqg for ; Fri, 8 Dec 2017 07:41:09 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7009F126FDC for ; Fri, 8 Dec 2017 07:41:09 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eNKlu-0005Jd-N6; Fri, 08 Dec 2017 15:41:06 +0000 From: "Jon Shallow" To: "'Roman Danyliw'" , References: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@marathon> Date: Fri, 8 Dec 2017 15:41:09 -0000 Message-ID: <065f01d3703a$f7fea070$e7fbe150$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHHfXSzmqKwHZYFhwmJOpGBCPQ/JKNReqwg Archived-At: Subject: Re: [Dots] Consensus call for early port allocation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:41:11 -0000 Hi Roman & Tobias, I support / concur with this request. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 08 December 2017 15:27 To: dots@ietf.org Subject: [Dots] Consensus call for early port allocation Hello WG! The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) have requested an early allocation of a port number from IANA per RFC7120. See https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. To proceed, WG consensus on this allocation is required (per step 3 of Section 3.1 of RFC7120). Please provide feedback on the mailing list on this topic by Friday, December 15. Regards, Roman and Tobias _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 8 07:42:50 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2527F126FDC for ; Fri, 8 Dec 2017 07:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=radwareil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxR7G8JPXPAm for ; Fri, 8 Dec 2017 07:42:46 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0122.outbound.protection.outlook.com [104.47.2.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1E2126D74 for ; Fri, 8 Dec 2017 07:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radwareil.onmicrosoft.com; s=selector1-radware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ngV81C1lyL5yq0SFIZCFWrvnlO+cSxRoctjxH7MGmEs=; b=eIvk2jx2BaUEYBwpGC8ff4sfHXNyeQlWC+w2ka0/OgDZRP8qP67Ex6tud49uO6i7ZQQI4EtoGub95uvhna05WI/nmD0zLivLPhFBsxX73YJpk5OGciwcCbU6CVZZ7r3THpmTUo/CgWhaVZF/7TloTycpQroM0duglURjFl5UCyg= Received: from AM6PR0102MB3143.eurprd01.prod.exchangelabs.com (52.133.17.140) by AM6PR0102MB3142.eurprd01.prod.exchangelabs.com (52.133.17.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 8 Dec 2017 15:42:44 +0000 Received: from AM6PR0102MB3143.eurprd01.prod.exchangelabs.com ([fe80::8c6:8754:770e:2abe]) by AM6PR0102MB3143.eurprd01.prod.exchangelabs.com ([fe80::8c6:8754:770e:2abe%13]) with mapi id 15.20.0302.011; Fri, 8 Dec 2017 15:42:44 +0000 From: Ehud Doron To: 'Roman Danyliw' , "dots@ietf.org" Thread-Topic: [Dots] Consensus call for early port allocation Thread-Index: AdNwNhVMEAJ7dCaQQ5e1tQiY+SmmtQABOJmAAAAMW6A= Date: Fri, 8 Dec 2017 15:42:43 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@marathon> <065f01d3703a$f7fea070$e7fbe150$@jpshallow.com> In-Reply-To: <065f01d3703a$f7fea070$e7fbe150$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=EhudD@Radware.com; x-originating-ip: [85.65.112.127] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0102MB3142; 6:K8lk9Td8ADWjESsWl/6Rs7LIOlbxYaRAxgDtBL9fWPuqdECfnLvEKcTsMKxdsWqwQKJzihMoUBD49l9YntltlIBYIzry2TUQjDUgPfOhpH4zWPLsV2/mmDLz00LJm7i7hVh6duVYs2MBGJjptkcHx6YaYZQVQSe13JdgsfJgd3swiDa+hJIVbBq166aNeoYyU3F+XZVLN/GngXe6nrDaTwiVBU3/t6jVTPYvUiqXh2CysDdQAB8Prn1kqFZTUwJvRnHm/RCb3C+JbdYpyop0LqrOnK1mZEAz3f0fYyfw9e44jmGNRiyOgMdrIiXZmnO6MObGGH17Dy+QBkvvBfyCYPufbL2nfa4XDeivw/nWGrg=; 5:Vj7Xe2bbKJdxaS+XyX2jzfluNSFLojtzMOa3VAFpEs5FTHfbsTvsRnyBZ4Vth/6bYHTsxmiNG3jz2jiy7fdezRqg6vbngBFu8GhvUPsbNoR7IFuddAnVFJA8TIIDHCV3MOcbZ+nyXORuLI99U3kX3RsvVLL4TSZaG+yXfevHtjY=; 24:dhOf49YRgOJ0wavOqHB5yZtPl4076OtEOhPa6MBvGciCU+B3mM1Grz7kcWVBjRzNbof+wbP++OOls4cizb5nONsBw0l4HTn2CqIZqiAZAP8=; 7:TkPbEPESY/Ewc7m0XnqaPGlQYCe8YEvMnyEXHzcB5/P8QW/T3MvkYR5kWm3J84D885NriFlXU68PRHGF+g8K27upoOqqbqR3BK0S/kZfo3CaTYC3kNpiPgk/AzvH9yCmnVdaXqiZYF4NivYsxh8450ba4Bq0scHT5yPdlDK/t4veK2ACK5kILY1zrDplSiax/7KNJAgpebovcL4oVQzIslTbjqPP2BZpVsrE2QVctyX3n0xU53TvSMmuS0FxJpgO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f6a3836e-7791-44bb-0b45-08d53e5252ce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:AM6PR0102MB3142; x-ms-traffictypediagnostic: AM6PR0102MB3142: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011); SRVR:AM6PR0102MB3142; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM6PR0102MB3142; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(189003)(199004)(13464003)(9686003)(2501003)(6306002)(68736007)(3846002)(5660300001)(102836003)(6116002)(80792005)(97736004)(966005)(99286004)(229853002)(14454004)(8936002)(86362001)(316002)(72206003)(7696005)(74316002)(478600001)(25786009)(76176011)(110136005)(6436002)(106356001)(53546010)(6506006)(53936002)(66066001)(33656002)(55016002)(7736002)(81166006)(2900100001)(81156014)(3660700001)(3280700002)(105586002)(2950100002)(6246003)(5250100002)(2906002)(305945005)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR0102MB3142; H:AM6PR0102MB3143.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: Radware.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: radware.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6a3836e-7791-44bb-0b45-08d53e5252ce X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 15:42:43.8862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ae4e000-b5d0-4f48-a766-402d46119b76 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0102MB3142 Archived-At: Subject: Re: [Dots] Consensus call for early port allocation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:42:49 -0000 Hi Support Thanks, Ehud -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 08, 2017 5:41 PM To: 'Roman Danyliw' ; dots@ietf.org Subject: Re: [Dots] Consensus call for early port allocation Hi Roman & Tobias, I support / concur with this request. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 08 December 2017 15:27 To: dots@ietf.org Subject: [Dots] Consensus call for early port allocation Hello WG! The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) have = requested an early allocation of a port number from IANA per RFC7120. See = https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. To proceed, WG consensus on this allocation is required (per step 3 of Sect= ion 3.1 of RFC7120). Please provide feedback on the mailing list on this t= opic by Friday, December 15. Regards, Roman and Tobias _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 8 07:58:17 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4165B1200B9; Fri, 8 Dec 2017 07:58:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151274869623.5904.10540351117210343910@ietfa.amsl.com> Date: Fri, 08 Dec 2017 07:58:16 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:58:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-10.txt Pages : 30 Date : 2017-12-08 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel"; o reference: RFC XXXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-10 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 8 08:02:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D296127137 for ; Fri, 8 Dec 2017 08:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3FlXq2NJa30 for ; Fri, 8 Dec 2017 08:02:37 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFF2120454 for ; Fri, 8 Dec 2017 08:02:36 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 2AF4C1C0BD3 for ; Fri, 8 Dec 2017 17:02:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 0926160074 for ; Fri, 8 Dec 2017 17:02:35 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 17:02:34 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt Thread-Index: AQHTcD1etlbkyjBm40S4jrE9sdlvA6M5mlCA Date: Fri, 8 Dec 2017 16:02:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0952C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151274869623.5904.10540351117210343910@ietfa.amsl.com> In-Reply-To: <151274869623.5904.10540351117210343910@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 16:02:38 -0000 Hi all,=20 The main change in this new version is to merge the two yang modules into o= ne single modules. Some nits and text reorganization were also implemented.= =20 Please review and share your comments.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 8 d=E9cembre 2017 16:58 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-10.txt > Pages : 30 > Date : 2017-12-08 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. >=20 > This is a companion document to the DOTS signal channel > specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel"; >=20 > o reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-10 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-10 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Dec 9 03:50:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFC9127698 for ; Sat, 9 Dec 2017 03:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrJ_jQMrgf0Y for ; Sat, 9 Dec 2017 03:50:18 -0800 (PST) Received: from sonic311-21.consmr.mail.gq1.yahoo.com (sonic311-21.consmr.mail.gq1.yahoo.com [98.137.65.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D403F1201F8 for ; Sat, 9 Dec 2017 03:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1512820218; bh=rPT2FN7X27CsqjjW7dfDw1rD/lCfCkb2UWlPxOttuOw=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=EOFiak1FA6yhhF5ioo43TyMM7tpBtaX1u/sWlFHAIW7ZZiVuLz4N1guy5J6mci4O8m0IrpBLBlt0WuoWZeKi9rcKOfLgrwfWUsZYuk2W+Z4cdH/s5RnnEEUjhDAVDcsxMLFCxEn0Q9yJpXp/z9FchpgTvYqnO82DbbSnvETYhIGrMpYCeTz5aLglE2iF/W3w1zE2JKIQq1UqvjPXyt71/oTDbY3S7NUy9TmcH/85R4ohJxuOBJjT30xryUsX/taYyyIDk5obFgcS+0Qvm16jrkahOenBMct2QyiCvTUDF8KybJQlOrQ9thZIvk/V73cAlRD5erYhDPkthvPIglFBmw== X-YMail-OSG: Fa52pqUVM1kWI06cZUJ9qfl2pW19phpHDwNVVVTdvx_IzCCQRQIafp0veJfh2BG Nr7Kje0kb9v1oFCU6Pli7nZjCVAaD0ijp3CdT8_L82hUUJGLcYZ53_hhmjew.vXKkjwx9F_MX7Ma 4Gm81SuU1DFiZcC8Llos96uhySqmI5xmZhNzvDHAe3OCdD0Szb11dDJYCgQGDiQw2XJojQGMolrS xlOcpP8Th6qPGx_QF0VhIqVU6VpvsuA72gllZMM3eZImn.IjmZ5oji47UFsNTYF9Ty7YIX3QFDCf s79X4STnEqcdbhJF6V2D98C7rJJM2236oJtrIBFoK2TEkCX4gLnCu5MF6BwU6qtRTBvH4Uh1biay qR6lyK1W5qKCr9GU.sGd0nea5YW.EHxXZP5IRsmYHhJLlWgX40pdy248bg09Omeo79RCpP25D_aV rd5MUPoCwlMYF6DykdkPA9JFzuI6An0qmbkP7zpVqJ46vC3yHONizvCa3XvEBgPfGzDpb6V6Jqe5 kuNgE Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Dec 2017 11:50:18 +0000 Date: Sat, 9 Dec 2017 11:50:14 +0000 (UTC) From: Nesredien Suleiman To: "dots@ietf.org" , Message-ID: <1287824950.1030809.1512820214336@mail.yahoo.com> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0952C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151274869623.5904.10540351117210343910@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A0952C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1030808_2005989505.1512820214334" X-Mailer: WebService/1.1.11051 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 11:50:21 -0000 ------=_Part_1030808_2005989505.1512820214334 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Med,I read the document and I found some of these =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Page , Last Paragraph= - thephrase "The server can respond to this request with either with a suc= cessor failure response " would be better if it is written as "The serverca= n respond to this request with either a success or failure response". =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Page 7, Section 5.2, = on thelast bullet - does "dropping or rate- limiting unwanted traffic"inclu= de black-listed traffics if so, how will the black-listed traffics be rate-= limited? =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Section 6.1, I don't = knowif I missed something from previous versions but I just wanted to know = thereason why the "Client-identifier" taken as optional attribute whereas t= he "alias-name" attribute a compulsory attribute. Peace to all,Nesredien On Friday, December 8, 2017, 7:02:42 PM GMT+3, wrote: =20 =20 Hi all,=20 The main change in this new version is to merge the two yang modules into o= ne single modules. Some nits and text reorganization were also implemented.= =20 Please review and share your comments.=20 Cheers, Med > -----Message d'origine----- > De=C2=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=C3=A9=C2=A0: vendredi 8 d=C3=A9cembre 2017 16:58 > =C3=80=C2=A0: i-d-announce@ietf.org > Cc=C2=A0: dots@ietf.org > Objet=C2=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Dist= ributed Denial-of-Service Open Threat > Signaling (DOTS) Data Channel >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tirumales= war Reddy >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mohamed Boucadair >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kaname Nishizuka >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Liang Xia >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Prashanth Patil >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Andrew Mortensen >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nik Teague > =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-dots-= data-channel-10.txt > =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 30 > =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017-1= 2-08 >=20 > Abstract: >=C2=A0 =C2=A0 The document specifies a Distributed Denial-of-Service Open = Threat >=C2=A0 =C2=A0 Signaling (DOTS) data channel used for bulk exchange of data= not >=C2=A0 =C2=A0 easily or appropriately communicated through the DOTS signal= channel >=C2=A0 =C2=A0 under attack conditions. >=20 >=C2=A0 =C2=A0 This is a companion document to the DOTS signal channel >=C2=A0 =C2=A0 specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 >=C2=A0 =C2=A0 Please update these statements with the RFC number to be ass= igned to >=C2=A0 =C2=A0 this document: >=20 >=C2=A0 =C2=A0 o=C2=A0 "This version of this YANG module is part of RFC XXX= X;" >=20 >=C2=A0 =C2=A0 o=C2=A0 "RFC XXXX: Distributed Denial-of-Service Open Threat= Signaling >=C2=A0 =C2=A0 =C2=A0 (DOTS) Data Channel"; >=20 >=C2=A0 =C2=A0 o=C2=A0 reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-10 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-10 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_Part_1030808_2005989505.1512820214334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Med,
I read the document and I found some = of these

=C2=B7         Page , Last Paragraph = - the phrase "The server can respond to this request with either with a success or failure response " would be better if it is written as "The server can respond to this request with either a success or failure response".

Page 7, Section 5.2, o= n the last bullet - does "dropping or rate- limiting unwanted traffic" include black-listed traffics if so, how will the black-listed traffics be = rate-limited?

<= span style=3D"font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-fo= nt-family:Symbol">=C2=B7 &nb= sp;       Section 6.1, I don't k= now if I missed something from previous versions but I just wanted to know the reason why the "Client-identifier" taken as optional attribute where as the "alias-name" attribute a compulsory attribute.

Peace to all,
Nesredien

=20
=20
On Friday, December 8, 2017, 7:02:42 PM GMT+3, <= ;mohamed.boucadair@orange.com> wrote:


Hi all,

The main change in this new version is to merge the two yang m= odules into one single modules. Some nits and text reorganization were also= implemented.

Please review and share= your comments.

Cheers,
Med

> -----Message d'origine--= ---
> De : Dots [mailto:dot= s-bounces@ietf.org] De la part de internet-
> drafts@ietf.org
> Envoy=C3=A9 : vendred= i 8 d=C3=A9cembre 2017 16:58
> =C3=80 : i-d-announce@ietf.org
> Cc : dots@ietf.org
> Objet : [Dots] I-D Action= : draft-ietf-dots-data-channel-10.txt
>
>
> A New Internet-Draft is available from th= e on-line Internet-Drafts
> directories.
> This draft is a work item of the DDoS Open Threat Signaling WG of= the
> IETF.
>
>        Title          = : Distributed Denial-of-Service Open Threat
> Signalin= g (DOTS) Data Channel
>        Au= thors        : Tirumaleswar Reddy
&g= t;                    &nb= sp;     Mohamed Boucadair
>    &n= bsp;                     = Kaname Nishizuka
>          =                 Liang Xia
>                 = ;         Prashanth Patil
> =                     &nbs= p;   Andrew Mortensen
>      &nbs= p;                   Nik Teag= ue
>     Filename      &= nbsp; : draft-ietf-dots-data-channel-10.txt
>  &n= bsp;  Pages          : 30
= >     Date            : 201= 7-12-08
>
> Abstract:
>    The document specifies a Distributed Denial-of-= Service Open Threat
>    Signaling (DOTS) da= ta channel used for bulk exchange of data not
>  =   easily or appropriately communicated through the DOTS signal channel=
>    under attack conditions.
>
>    This is a companion document= to the DOTS signal channel
>    specificati= on.
>
> Editorial Note (To be re= moved by RFC Editor)
>
>  &= nbsp; Please update these statements with the RFC number to be assigned to<= br clear=3D"none">>    this document:
> <= br clear=3D"none">>    o  "This version of this YANG modu= le is part of RFC XXXX;"
>
>&nbs= p;   o  "RFC XXXX: Distributed Denial-of-Service Open Threat Sign= aling
>      (DOTS) Data Channel";
>
>    o  reference:= RFC XXXX
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dra= ft-ietf-dots-data-channel/
>
&g= t; There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dots-dat= a-channel-10
> https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-10<= /a>
>
> A diff from the previous= version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channe= l-10
>
>
= > Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized ver= sion and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:<= br clear=3D"none">> ftp://ftp.ietf.org/internet-drafts/
>
> __________________________________= _____________
> Dots mailing list
&g= t; Dots@ietf.org
> https://www.= ietf.org/mailman/listinfo/dots


_______________________________= ________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mai= lman/listinfo/dots
------=_Part_1030808_2005989505.1512820214334-- From nobody Sun Dec 10 22:45:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC78012717E for ; Sun, 10 Dec 2017 22:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVsiT8r8DbzB for ; Sun, 10 Dec 2017 22:45:32 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8ADE1270A7 for ; Sun, 10 Dec 2017 22:45:31 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 5B74C40B41; Mon, 11 Dec 2017 07:45:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 3B3851C005D; Mon, 11 Dec 2017 07:45:30 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0361.001; Mon, 11 Dec 2017 07:45:30 +0100 From: To: Nesredien Suleiman , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt Thread-Index: AQHTcOPfhZLThVaA9kuKibTKB/Y5+6M9rd4w Date: Mon, 11 Dec 2017 06:45:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0958DC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151274869623.5904.10540351117210343910@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A0952C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1287824950.1030809.1512820214336@mail.yahoo.com> In-Reply-To: <1287824950.1030809.1512820214336@mail.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0958DCOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 06:45:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0958DCOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmVzcmVkaWVuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNClBsZWFzZSBzZWUg aW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBOZXNyZWRpZW4gU3VsZWltYW4gW21haWx0 bzptaG5zYXNAeWFob28uY29tXQ0KRW52b3nDqSA6IHNhbWVkaSA5IGTDqWNlbWJyZSAyMDE3IDEy OjUwDQrDgCA6IGRvdHNAaWV0Zi5vcmc7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCk9iamV0 IDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTEw LnR4dA0KDQpIZWxsbyBNZWQsDQpJIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBJIGZvdW5kIHNvbWUg b2YgdGhlc2UNCg0K4oCiICAgICAgICAgUGFnZSAsIExhc3QgUGFyYWdyYXBoIC0gdGhlIHBocmFz ZSAiVGhlIHNlcnZlciBjYW4gcmVzcG9uZCB0byB0aGlzIHJlcXVlc3Qgd2l0aCBlaXRoZXIgd2l0 aCBhIHN1Y2Nlc3Mgb3IgZmFpbHVyZSByZXNwb25zZSAiIHdvdWxkIGJlIGJldHRlciBpZiBpdCBp cyB3cml0dGVuIGFzICJUaGUgc2VydmVyIGNhbiByZXNwb25kIHRvIHRoaXMgcmVxdWVzdCB3aXRo IGVpdGhlciBhIHN1Y2Nlc3Mgb3IgZmFpbHVyZSByZXNwb25zZSIuDQoNCltNZWRdIEZpeGVkLg0K DQrigKIgICAgICAgICBQYWdlIDcsIFNlY3Rpb24gNS4yLCBvbiB0aGUgbGFzdCBidWxsZXQgLSBk b2VzICJkcm9wcGluZyBvciByYXRlLSBsaW1pdGluZyB1bndhbnRlZCB0cmFmZmljIiBpbmNsdWRl IGJsYWNrLWxpc3RlZCB0cmFmZmljcyBpZiBzbywgaG93IHdpbGwgdGhlIGJsYWNrLWxpc3RlZCB0 cmFmZmljcyBiZSByYXRlLWxpbWl0ZWQ/DQoNCltNZWRdIEFDTHMgY2FuIGJlIHVzZWQgdG8gaW5z dHJ1Y3QgdGhlIHNlcnZlciB0byBibGFja2xpc3Qgc29tZSB0cmFmZmljIHRoYXQgbWF0Y2ggc29t ZSBjb25kaXRpb25zLiBBbHNvLCBBQ0xzIGNhbiBiZSB1c2VkIHRvIHJhdGUtbGltdCBzb21lIHRy YWZmaWMuIEhvdyB0aG9zZSBwb2xpY2llcyBhcmUgZW5jb3JlZCBhdCB0aGUgc2VydmVy4oCZcyBz aWRlIGlzIGltcGxlbWVudGF0aW9uL2RlcGxveW1lbnQgc3BlY2lmaWMuIEZvciBleGFtcGxlLA0K DQotICAgIGEgZG90cyBkYXRhIGNoYW5uZWwgbWVzc2FnZSBjYW4gdHJpZ2dlciBCR1AgbWVzc2Fn ZXMgd2l0aCBmbG93IHNwZWMgTkxSSXMgdG8gYmUgYWR2ZXJ0aXNlZCBpbiB0aGUgdXBzdHJlYW0g ZG9tYWluLg0KDQotICAgIGEgZG90cyBkYXRhIGNoYW5uZWwgbWVzc2FnZSBjYW4gdHJpZ2dlciBO RVRDT05GIG1lc3NhZ2VzIHRvIGVuZm9yY2UgcG9saWNpZXMgb24gdGhlIGFwcHJvcHJpYXRlIG5l dHdvcmsgZGV2aWNlcy4NCg0K4oCiICAgICAgICAgU2VjdGlvbiA2LjEsIEkgZG9uJ3Qga25vdyBp ZiBJIG1pc3NlZCBzb21ldGhpbmcgZnJvbSBwcmV2aW91cyB2ZXJzaW9ucyBidXQgSSBqdXN0IHdh bnRlZCB0byBrbm93IHRoZSByZWFzb24gd2h5IHRoZSAiQ2xpZW50LWlkZW50aWZpZXIiIHRha2Vu IGFzIG9wdGlvbmFsIGF0dHJpYnV0ZSB3aGVyZSBhcyB0aGUgImFsaWFzLW5hbWUiIGF0dHJpYnV0 ZSBhIGNvbXB1bHNvcnkgYXR0cmlidXRlLg0KDQpbTWVkXSBjbGllbnQtaWRlbnRpZmllciBpcyBv cHRpb25hbCBiZWNhdXNlIGEgZG90cyBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBjb252ZXkgYW4g ZXh0cmEgaWRlbnRpZmllciBpbiBpdHMgbWVzc2FnZXMgZGVzdGluZWQgdG8gYW4gdXBzdHJlYW0g ZG90cyBzZXJ2ZXIgYmVjYXVzZSBpZGVudGlmaWNhdGlvbiB0YWtlcyBwbGFjZSBkdXJpbmcgYXV0 aGVudGljYXRpb24uIExpa2V3aXNlLCBhIGNsaWVudC1zaWRlIGdhdGV3YXkgKHRoYXQgaXMsIGEg ZG90cyBnYXRld2F5IGxvY2F0ZWQgaW4gdGhlIGNsaWVudOKAmXMgZG9tYWluKSBtdXN0IG5vdCBs ZWFrIGluZm9ybWF0aW9uIGFib3V0IGludGVybmFsIGRvdHMgY2xpZW50cyAoZm9yIHByaXZhY3kg cmVhc29ucykuIFRoZSBvbmx5IGNhc2Ugd2hlcmUgY2xpZW50LWlkZW50aWZpZXIgaXMgbmVlZGVk LCBpcyB3aGVyZSBhIHNlcnZlci1zaWRlIGdhdGV3YXkgaXMgbG9jYXRlZCBvbi1wYXRoLiBJbiBz dWNoIGNhc2UsIGEgc2VydmVyLXNpZGUgZ2F0ZXdheSBpbnNlcnRzIGl0IHRvIGhlbHAgdGhlIHNl cnZlciBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIHBvbGljeSB0byBiZSBlbmZvcmNlZCBmb3IgdGhl IGNsaWVudC4NClBlYWNlIHRvIGFsbCwNCk5lc3JlZGllbg0KDQpPbiBGcmlkYXksIERlY2VtYmVy IDgsIDIwMTcsIDc6MDI6NDIgUE0gR01UKzMsIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNCg0KSGkgYWxs LA0KDQpUaGUgbWFpbiBjaGFuZ2UgaW4gdGhpcyBuZXcgdmVyc2lvbiBpcyB0byBtZXJnZSB0aGUg dHdvIHlhbmcgbW9kdWxlcyBpbnRvIG9uZSBzaW5nbGUgbW9kdWxlcy4gU29tZSBuaXRzIGFuZCB0 ZXh0IHJlb3JnYW5pemF0aW9uIHdlcmUgYWxzbyBpbXBsZW1lbnRlZC4NCg0KUGxlYXNlIHJldmll dyBhbmQgc2hhcmUgeW91ciBjb21tZW50cy4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gRGUgbGEgcGFydCBkZSBpbnRlcm5l dC0NCj4gZHJhZnRzQGlldGYub3JnPG1haWx0bzpkcmFmdHNAaWV0Zi5vcmc+DQo+IEVudm95w6kg OiB2ZW5kcmVkaSA4IGTDqWNlbWJyZSAyMDE3IDE2OjU4DQo+IMOAIDogaS1kLWFubm91bmNlQGll dGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+IENjIDogZG90c0BpZXRmLm9y ZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NCj4gT2JqZXQgOiBbRG90c10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0xMC50eHQNCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRp cmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9TIE9wZW4g VGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0aGUNCj4gSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAg ICAgICAgIDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCj4gU2ln bmFsaW5nIChET1RTKSBEYXRhIENoYW5uZWwNCj4gICAgICAgIEF1dGhvcnMgICAgICAgIDogVGly dW1hbGVzd2FyIFJlZGR5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNb2hhbWVkIEJvdWNh ZGFpcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgS2FuYW1lIE5pc2hpenVrYQ0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgTGlhbmcgWGlhDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICBQcmFzaGFudGggUGF0aWwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEFuZHJldyBNb3J0 ZW5zZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIE5payBUZWFndWUNCj4gICAgIEZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMTAudHh0DQo+ICAgICBQ YWdlcyAgICAgICAgICA6IDMwDQo+ICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3LTEyLTA4DQo+ DQo+IEFic3RyYWN0Og0KPiAgICBUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIGEgRGlzdHJpYnV0ZWQg RGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCj4gICAgU2lnbmFsaW5nIChET1RTKSBkYXRh IGNoYW5uZWwgdXNlZCBmb3IgYnVsayBleGNoYW5nZSBvZiBkYXRhIG5vdA0KPiAgICBlYXNpbHkg b3IgYXBwcm9wcmlhdGVseSBjb21tdW5pY2F0ZWQgdGhyb3VnaCB0aGUgRE9UUyBzaWduYWwgY2hh bm5lbA0KPiAgICB1bmRlciBhdHRhY2sgY29uZGl0aW9ucy4NCj4NCj4gICAgVGhpcyBpcyBhIGNv bXBhbmlvbiBkb2N1bWVudCB0byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0KPiAgICBzcGVjaWZp Y2F0aW9uLg0KPg0KPiBFZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9y KQ0KPg0KPiAgICBQbGVhc2UgdXBkYXRlIHRoZXNlIHN0YXRlbWVudHMgd2l0aCB0aGUgUkZDIG51 bWJlciB0byBiZSBhc3NpZ25lZCB0bw0KPiAgICB0aGlzIGRvY3VtZW50Og0KPg0KPiAgICBvICAi VGhpcyB2ZXJzaW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWDsiDQo+ DQo+ICAgIG8gICJSRkMgWFhYWDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBU aHJlYXQgU2lnbmFsaW5nDQo+ICAgICAgKERPVFMpIERhdGEgQ2hhbm5lbCI7DQo+DQo+ICAgIG8g IHJlZmVyZW5jZTogUkZDIFhYWFgNCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwvDQo+DQo+IFRoZXJlIGFyZSBhbHNvIGh0 bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMTANCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTEwDQo+DQo+ IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5u ZWwtMTANCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0K PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0 DQo+IERvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9y ZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG90cw0K --_000_787AE7BB302AE849A7480A190F8B93300A0958DCOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlkcDhkMGE5MTE3bXNvbGlzdHBhcmFn cmFwaCwgbGkueWRwOGQwYTkxMTdtc29saXN0cGFyYWdyYXBoLCBkaXYueWRwOGQwYTkxMTdtc29s aXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOnlkcDhkMGE5MTE3bXNvbGlzdHBhcmFncmFw aDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4OTE1NzkzMTQ7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDU5MzcyMzE0IC0xMDM3OTE4 ODggNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcg Njc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDot Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgTmVzcmVkaWVuLA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciB0aGUgcmV2 aWV3Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5lc3JlZGllbiBTdWxlaW1hbiBbbWFp bHRvOm1obnNhc0B5YWhvby5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gc2FtZWRp IDkgZMOpY2VtYnJlIDIwMTcgMTI6NTA8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGRvdHNAaWV0Zi5v cmc7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJl OiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0xMC50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkhlbGxvIE1lZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHJlYWQgdGhlIGRvY3Vt ZW50IGFuZCBJIGZvdW5kIHNvbWUgb2YgdGhlc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieWRwOGQwYTkxMTdtc29saXN0cGFyYWdyYXBoIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYWdlICwgTGFzdCBQYXJhZ3JhcGggLSB0aGUgcGhyYXNlICZx dW90O1RoZSBzZXJ2ZXIgY2FuIHJlc3BvbmQgdG8gdGhpcyByZXF1ZXN0IHdpdGggZWl0aGVyIHdp dGggYSBzdWNjZXNzIG9yIGZhaWx1cmUgcmVzcG9uc2UgJnF1b3Q7IHdvdWxkIGJlIGJldHRlciBp ZiBpdCBpcyB3cml0dGVuIGFzICZxdW90O1RoZSBzZXJ2ZXIgY2FuIHJlc3BvbmQgdG8gdGhpcyBy ZXF1ZXN0IHdpdGgNCiBlaXRoZXIgYSBzdWNjZXNzIG9yIGZhaWx1cmUgcmVzcG9uc2UmcXVvdDsu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InlkcDhkMGE5MTE3bXNvbGlzdHBhcmFn cmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEZpeGVkLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9InlkcDhkMGE5MTE3bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYWdlIDcsIFNlY3Rp b24gNS4yLCBvbiB0aGUgbGFzdCBidWxsZXQgLSBkb2VzICZxdW90O2Ryb3BwaW5nIG9yIHJhdGUt IGxpbWl0aW5nIHVud2FudGVkIHRyYWZmaWMmcXVvdDsgaW5jbHVkZSBibGFjay1saXN0ZWQgdHJh ZmZpY3MgaWYgc28sIGhvdyB3aWxsIHRoZSBibGFjay1saXN0ZWQgdHJhZmZpY3MgYmUgcmF0ZS1s aW1pdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJ5ZHA4ZDBhOTExN21zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gQUNM cyBjYW4gYmUgdXNlZCB0byBpbnN0cnVjdCB0aGUgc2VydmVyIHRvIGJsYWNrbGlzdCBzb21lIHRy YWZmaWMgdGhhdCBtYXRjaCBzb21lIGNvbmRpdGlvbnMuIEFsc28sIEFDTHMgY2FuIGJlIHVzZWQg dG8gcmF0ZS1saW10DQogc29tZSB0cmFmZmljLiBIb3cgdGhvc2UgcG9saWNpZXMgYXJlIGVuY29y ZWQgYXQgdGhlIHNlcnZlcuKAmXMgc2lkZSBpcyBpbXBsZW1lbnRhdGlvbi9kZXBsb3ltZW50IHNw ZWNpZmljLiBGb3IgZXhhbXBsZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJ5 ZHA4ZDBhOTExN21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+YSBkb3RzIGRhdGEgY2hh bm5lbCBtZXNzYWdlIGNhbiB0cmlnZ2VyIEJHUCBtZXNzYWdlcyB3aXRoIGZsb3cgc3BlYyBOTFJJ cyB0byBiZSBhZHZlcnRpc2VkIGluIHRoZSB1cHN0cmVhbSBkb21haW4uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0ieWRwOGQwYTkxMTdtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPmEgZG90cyBkYXRhIGNoYW5uZWwgbWVzc2FnZSBjYW4gdHJpZ2dlciBORVRDT05GIG1l c3NhZ2VzIHRvIGVuZm9yY2UgcG9saWNpZXMgb24gdGhlIGFwcHJvcHJpYXRlIG5ldHdvcmsgZGV2 aWNlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJ5ZHA4ZDBhOTExN21zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rpb24gNi4xLCBJIGRv bid0IGtub3cgaWYgSSBtaXNzZWQgc29tZXRoaW5nIGZyb20gcHJldmlvdXMgdmVyc2lvbnMgYnV0 IEkganVzdCB3YW50ZWQgdG8ga25vdyB0aGUgcmVhc29uIHdoeSB0aGUgJnF1b3Q7Q2xpZW50LWlk ZW50aWZpZXImcXVvdDsgdGFrZW4gYXMgb3B0aW9uYWwgYXR0cmlidXRlIHdoZXJlIGFzIHRoZSAm cXVvdDthbGlhcy1uYW1lJnF1b3Q7IGF0dHJpYnV0ZSBhDQogY29tcHVsc29yeSBhdHRyaWJ1dGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InlkcDhkMGE5MTE3bXNvbGlzdHBhcmFn cmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBjbGllbnQtaWRl bnRpZmllciBpcyBvcHRpb25hbCBiZWNhdXNlIGEgZG90cyBjbGllbnQgZG9lcyBub3QgbmVlZCB0 byBjb252ZXkgYW4gZXh0cmEgaWRlbnRpZmllciBpbiBpdHMgbWVzc2FnZXMgZGVzdGluZWQgdG8g YW4gdXBzdHJlYW0NCiBkb3RzIHNlcnZlciBiZWNhdXNlIGlkZW50aWZpY2F0aW9uIHRha2VzIHBs YWNlIGR1cmluZyBhdXRoZW50aWNhdGlvbi4gTGlrZXdpc2UsIGEgY2xpZW50LXNpZGUgZ2F0ZXdh eSAodGhhdCBpcywgYSBkb3RzIGdhdGV3YXkgbG9jYXRlZCBpbiB0aGUgY2xpZW504oCZcyBkb21h aW4pIG11c3Qgbm90IGxlYWsgaW5mb3JtYXRpb24gYWJvdXQgaW50ZXJuYWwgZG90cyBjbGllbnRz IChmb3IgcHJpdmFjeSByZWFzb25zKS4gVGhlIG9ubHkgY2FzZSB3aGVyZQ0KIGNsaWVudC1pZGVu dGlmaWVyIGlzIG5lZWRlZCwgaXMgd2hlcmUgYSBzZXJ2ZXItc2lkZSBnYXRld2F5IGlzIGxvY2F0 ZWQgb24tcGF0aC4gSW4gc3VjaCBjYXNlLCBhIHNlcnZlci1zaWRlIGdhdGV3YXkgaW5zZXJ0cyBp dCB0byBoZWxwIHRoZSBzZXJ2ZXIgc2VsZWN0IHRoZSBhcHByb3ByaWF0ZSBwb2xpY3kgdG8gYmUg ZW5mb3JjZWQgZm9yIHRoZSBjbGllbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QZWFjZSB0byBhbGwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TmVz cmVkaWVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ5YWhvb19xdW90ZWRfMzE0MDQ1NjE0MCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMjYyODJBIj5PbiBGcmlkYXksIERlY2VtYmVyIDgsIDIwMTcsIDc6MDI6NDIgUE0g R01UJiM0MzszLCAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMyNjI4MkEiPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj48 c3BhbiBsYW5nPSJFTi1VUyI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjYyODJBIj4mZ3Q7DQogd3JvdGU6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPkhpIGFsbCwNCjxicj4NCjxi cj4NClRoZSBtYWluIGNoYW5nZSBpbiB0aGlzIG5ldyB2ZXJzaW9uIGlzIHRvIG1lcmdlIHRoZSB0 d28geWFuZyBtb2R1bGVzIGludG8gb25lIHNpbmdsZSBtb2R1bGVzLiBTb21lIG5pdHMgYW5kIHRl eHQgcmVvcmdhbml6YXRpb24gd2VyZSBhbHNvIGltcGxlbWVudGVkLg0KPGJyPg0KPGJyPg0KUGxl YXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21tZW50cy4gPGJyPg0KPGJyPg0KQ2hlZXJzLDxi cj4NCk1lZDxicj4NCjxicj4NCiZndDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0K Jmd0OyBEZSZuYnNwOzogRG90cyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGUgaW50ZXJu ZXQtPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnRzQGlldGYub3JnIj5kcmFmdHNAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyBFbnZvecOpJm5ic3A7OiB2ZW5kcmVkaSA4IGTDqWNlbWJyZSAy MDE3IDE2OjU4PGJyPg0KJmd0OyDDgCZuYnNwOzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgQ2MmbmJzcDs6 IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCiZn dDsgT2JqZXQmbmJzcDs6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1j aGFubmVsLTEwLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0czxi cj4NCiZndDsgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0aGU8YnI+DQomZ3Q7IElF VEYuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxl Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IERpc3RyaWJ1dGVkIERlbmlhbC1v Zi1TZXJ2aWNlIE9wZW4gVGhyZWF0PGJyPg0KJmd0OyBTaWduYWxpbmcgKERPVFMpIERhdGEgQ2hh bm5lbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9ycyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTW9oYW1lZCBCb3VjYWRhaXI8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEthbmFtZSBOaXNoaXp1a2E8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExpYW5nIFhpYTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUHJhc2hhbnRoIFBhdGlsPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbmRyZXcgTW9ydGVuc2VuPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOaWsgVGVhZ3VlPGJyPg0KJmd0OyAm bmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBk cmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTEwLnR4dDxicj4NCiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDMwPGJyPg0K Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDogMjAxNy0xMi0wODxicj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFjdDo8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIGEgRGlzdHJpYnV0 ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBT aWduYWxpbmcgKERPVFMpIGRhdGEgY2hhbm5lbCB1c2VkIGZvciBidWxrIGV4Y2hhbmdlIG9mIGRh dGEgbm90PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgZWFzaWx5IG9yIGFwcHJvcHJpYXRlbHkgY29t bXVuaWNhdGVkIHRocm91Z2ggdGhlIERPVFMgc2lnbmFsIGNoYW5uZWw8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB1bmRlciBhdHRhY2sgY29uZGl0aW9ucy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsgJm5ic3A7IFRoaXMgaXMgYSBjb21wYW5pb24gZG9jdW1lbnQgdG8gdGhlIERPVFMgc2lnbmFs IGNoYW5uZWw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBzcGVjaWZpY2F0aW9uLjxicj4NCiZndDsg PGJyPg0KJmd0OyBFZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKTxi cj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgUGxlYXNlIHVwZGF0ZSB0aGVzZSBzdGF0 ZW1lbnRzIHdpdGggdGhlIFJGQyBudW1iZXIgdG8gYmUgYXNzaWduZWQgdG88YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyB0aGlzIGRvY3VtZW50Ojxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgbyZuYnNwOyAmcXVvdDtUaGlzIHZlcnNpb24gb2YgdGhpcyBZQU5HIG1vZHVsZSBpcyBwYXJ0 IG9mIFJGQyBYWFhYOyZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbyZu YnNwOyAmcXVvdDtSRkMgWFhYWDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBU aHJlYXQgU2lnbmFsaW5nPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IChET1RTKSBEYXRh IENoYW5uZWwmcXVvdDs7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBvJm5ic3A7 IHJlZmVyZW5jZTogUkZDIFhYWFg8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90 cy1kYXRhLWNoYW5uZWwvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLzwvYT48YnI+DQomZ3Q7IDxi cj4NCiZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt ZG90cy1kYXRhLWNoYW5uZWwtMTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTEwPC9hPjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LWRvdHMtZGF0YS1jaGFubmVsLTEwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMTA8L2E+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTEwIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kb3RzLWRh dGEtY2hhbm5lbC0xMDwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zjxicj4NCiZndDsgc3VibWlzc2lvbjxicj4NCiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LzwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IERvdHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8 YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5cXRmZDg5NTEwIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNjI4MkEi Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KRG90cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86RG90c0BpZXRm Lm9yZyI+RG90c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A0958DCOPEXCLILMA3corp_-- From nobody Thu Dec 14 07:08:41 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B28126D3F; Thu, 14 Dec 2017 07:08:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151326411899.6067.16079347190768583372@ietfa.amsl.com> Date: Thu, 14 Dec 2017 07:08:39 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-13.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:08:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-13.txt Pages : 77 Date : 2017-12-14 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX o This RFC Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-13 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-13 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 14 07:21:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58F126BF6 for ; Thu, 14 Dec 2017 07:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnIiFWZlsLWV for ; Thu, 14 Dec 2017 07:21:52 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CB4126D3F for ; Thu, 14 Dec 2017 07:21:51 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4B8832083A for ; Thu, 14 Dec 2017 16:21:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 2F0D51A0063 for ; Thu, 14 Dec 2017 16:21:50 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Thu, 14 Dec 2017 16:21:47 +0100 From: To: "dots@ietf.org" CC: JACQUENET Christian IMT/OLN Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-13.txt Thread-Index: AQHTdO1u5K0OjKdTdEWKiK2tK3OcO6NC8RiA Date: Thu, 14 Dec 2017 15:21:25 +0000 Message-ID: <92fe250d-3d92-451a-b2f3-27865df96876@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <151326411899.6067.16079347190768583372@ietfa.amsl.com> In-Reply-To: <151326411899.6067.16079347190768583372@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] TR: I-D Action: draft-ietf-dots-signal-channel-13.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:21:54 -0000 Hi all,=20 A new version is out! The main changes are as follows: - Integrate the detailed comments from Christian. Many thanks to him! - Double check the normative language. - Add NEW text to discuss considerations related to the presence of transla= tors - Remove target-ip because it is redundant with target-prefix - Update the text to indicate the required behavior for inserting/removing = client-identifier by gateways - Update the text to clearly specify the error codes to be returned - Add a new parameter called "config-interval" to force a dots client to re= trieve new config from the server. This is particularly useful for a DOTS s= erver that want to instruct a client to reduce the frequency of heartbeat o= r even to cease them. - heartbeat-interval can now be set to '0' - Update the YANG module - Add a pointer to the mechanisms required to prevent replay attack when TL= S1.3 0-RTT is in use. As usual, feel free to review and share comments. Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 14 d=E9cembre 2017 16:09 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-13.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-13.txt > Pages : 77 > Date : 2017-12-14 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-13 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-13 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 14 21:09:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E13126FB3 for ; Thu, 14 Dec 2017 21:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMwZ2WYvYaRj for ; Thu, 14 Dec 2017 21:09:50 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 93757126C22 for ; Thu, 14 Dec 2017 21:09:50 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id CE65525F691; Fri, 15 Dec 2017 14:09:48 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id AD54A75900C; Fri, 15 Dec 2017 14:09:48 +0900 (JST) To: Ehud Doron , 'Roman Danyliw' , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@marathon> <065f01d3703a$f7fea070$e7fbe150$@jpshallow.com> From: kaname nishizuka Message-ID: <4fa52666-44f0-e160-25f9-f3a74c41353c@nttv6.jp> Date: Fri, 15 Dec 2017 14:09:51 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] Consensus call for early port allocation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 05:09:53 -0000 I support the request. thank you, Kaname On 2017/12/09 0:42, Ehud Doron wrote: > Hi > > Support > > Thanks, Ehud > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Friday, December 08, 2017 5:41 PM > To: 'Roman Danyliw' ; dots@ietf.org > Subject: Re: [Dots] Consensus call for early port allocation > > Hi Roman & Tobias, > > I support / concur with this request. > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: 08 December 2017 15:27 > To: dots@ietf.org > Subject: [Dots] Consensus call for early port allocation > > Hello WG! > > The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) have requested an early allocation of a port number from IANA per RFC7120. See https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. > > To proceed, WG consensus on this allocation is required (per step 3 of Section 3.1 of RFC7120). Please provide feedback on the mailing list on this topic by Friday, December 15. > > Regards, > Roman and Tobias > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 14 21:19:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836EB126C22 for ; Thu, 14 Dec 2017 21:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ3kWqlwpwNM for ; Thu, 14 Dec 2017 21:19:03 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id ED741126B7E for ; Thu, 14 Dec 2017 21:19:02 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id A299625F698; Fri, 15 Dec 2017 14:19:01 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 4845E7634F2; Fri, 15 Dec 2017 14:19:01 +0900 (JST) To: mohamed.boucadair@orange.com, Roman Danyliw , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> <787AE7BB302AE849A7480A190F8B93300A0950AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <4783df7e-3a98-2c8d-1c92-e85f73e292bd@nttv6.jp> Date: Fri, 15 Dec 2017 14:19:00 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0950AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 05:19:05 -0000 Hi, I support the document to go WGLC process. I also support the comment from Med which is adding SEC-005. It reflects the latest discussion about the client identifier. > - Add some text about the expected behavior of client-side DOTS gateways to prevent leaking privacy information + server-side DOTS gateways to help servers to enforce policies. thank you, Kaname On 2017/12/08 18:40, mohamed.boucadair@orange.com wrote: > Hi all, > > I support this document to be advanced in the publication process. > > I have the following comments: > - Align the text with the outcome of recent discussions: for example, supplying a lifetime is a MUST. > - Add some text about the expected behavior of client-side DOTS gateways to prevent leaking privacy information + server-side DOTS gateways to help servers to enforce policies. > - Add some text about resolution libraries at DOTS servers to handle requests having FQDN/URIs as mitigation scope. > - Update DM versioning requirement; no need to mention the text about version 1. > > The detailed comments and other easy-to-fix nits are available at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-dots-requirements-08-rev%20Med.pdf > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw >> Envoyé : jeudi 7 décembre 2017 21:51 >> À : dots@ietf.org >> Objet : [Dots] WGLC on DOTS Requirements >> >> Hello! >> >> Consistent with our discussion at the Singapore meeting and with the >> concurrence of the draft authors, we are starting a working group last >> call (WGLC) for the DOTS Requirements draft: >> >> Distributed Denial of Service (DDoS) Open Threat Signaling Requirements >> draft-ietf-dots-requirements-08 >> https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >> >> Please send all comments to the DOTS mailing list. >> >> This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the- >> calendar year vacations). >> >> Thanks, >> Roman >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 14 23:14:43 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF52126FB3 for ; Thu, 14 Dec 2017 23:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idPgzTz9NtRx for ; Thu, 14 Dec 2017 23:14:40 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3471124BFA for ; Thu, 14 Dec 2017 23:14:39 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 512B9C0A03 for ; Fri, 15 Dec 2017 08:14:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 9F64320070 for ; Fri, 15 Dec 2017 08:14:35 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0361.001; Fri, 15 Dec 2017 08:14:32 +0100 From: To: "dots@ietf.org" CC: JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-signal-channel-13.txt Thread-Index: AQHTdO1uG0uvaRQtdUq+l0mSS7DkSaNC8RiAgAEKBjA= Date: Fri, 15 Dec 2017 07:14:31 +0000 Message-ID: <5580a619-3ceb-4d35-9906-b16ff55b922f@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <151326411899.6067.16079347190768583372@ietfa.amsl.com> <92fe250d-3d92-451a-b2f3-27865df96876@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <92fe250d-3d92-451a-b2f3-27865df96876@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-signal-channel-13.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 07:14:42 -0000 Hi all,=20 There is an error in -13 about CBOR major key for acl-name. The required ch= ange to fix it is as follows: OLD: | Parameter name | CBOR key | CBOR major type of value | +----------------------+----------------+--------------------------+ | acl-name | 42 | 2 | NEW: | Parameter name | CBOR key | CBOR major type of value | +----------------------+----------------+--------------------------+ | acl-name | 42 | 3 | Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: jeudi 14 d=E9cembre 2017 16:21 > =C0=A0: dots@ietf.org > Cc=A0: JACQUENET Christian IMT/OLN > Objet=A0: [Dots] TR: I-D Action: draft-ietf-dots-signal-channel-13.txt >=20 > Hi all, >=20 > A new version is out! >=20 > The main changes are as follows: > - Integrate the detailed comments from Christian. Many thanks to him! > - Double check the normative language. > - Add NEW text to discuss considerations related to the presence of > translators > - Remove target-ip because it is redundant with target-prefix > - Update the text to indicate the required behavior for inserting/removin= g > client-identifier by gateways > - Update the text to clearly specify the error codes to be returned > - Add a new parameter called "config-interval" to force a dots client to > retrieve new config from the server. This is particularly useful for a > DOTS server that want to instruct a client to reduce the frequency of > heartbeat or even to cease them. > - heartbeat-interval can now be set to '0' > - Update the YANG module > - Add a pointer to the mechanisms required to prevent replay attack when > TLS1.3 0-RTT is in use. >=20 > As usual, feel free to review and share comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org > > Envoy=E9=A0: jeudi 14 d=E9cembre 2017 16:09 > > =C0=A0: i-d-announce@ietf.org > > Cc=A0: dots@ietf.org > > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-13.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the > > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-13.txt > > Pages : 77 > > Date : 2017-12-14 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > o This RFC > > > > Please update TBD statements with the port number to be assigned to > > DOTS Signal Channel Protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-13 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-13 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 15 06:19:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71E1128C9C for ; Fri, 15 Dec 2017 06:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZZYFjY_3Wl2 for ; Fri, 15 Dec 2017 06:19:47 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7590C12871F for ; Fri, 15 Dec 2017 06:19:47 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 0CC8C6092C for ; Fri, 15 Dec 2017 15:19:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id E2C73C0068 for ; Fri, 15 Dec 2017 15:19:45 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Fri, 15 Dec 2017 15:19:45 +0100 From: To: "dots@ietf.org" Thread-Topic: client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2row== Date: Fri, 15 Dec 2017 14:19:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A099584OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 14:19:49 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A099584OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG1=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG1=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A099584OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG1=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

- = ;   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

- = ;   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG1=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A099584OPEXCLILMA3corp_-- From nobody Fri Dec 15 08:54:00 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17617126C83 for ; Fri, 15 Dec 2017 08:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6rcgN83X6jZ for ; Fri, 15 Dec 2017 08:53:57 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE3A127241 for ; Fri, 15 Dec 2017 08:53:56 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vBFGrtc1009656 for ; Fri, 15 Dec 2017 11:53:55 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vBFGrtc1009656 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1513356835; bh=VHyXh/rgKySh6BUp7+I1U9m435XdC4oOoTXjek58Nk4=; h=From:To:Subject:Date:From; b=Vz8wxDUm9JBVzLxVULuAZ6vyGVuf5LDG1cQi8otUwe3fppPZQDSmLkuvhrVEmCQAz TASaL5Y3hp8Xfb3d/56++BfAFC/uKGr1ogLPPCgegTRMTO8Z6eumdBEbVDz7X3ebDo bMtuDtkPr7hvAHhn3vZPlmajVKw6Gsg+l7mU6wtU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vBFGrm9D019926 for ; Fri, 15 Dec 2017 11:53:48 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Fri, 15 Dec 2017 11:53:48 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Reminder -- Consensus call for early port allocation Thread-Index: AdN1xR550yEgNlqXRZKyIcfkgesAGg== Date: Fri, 15 Dec 2017 16:53:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131347BF8@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Reminder -- Consensus call for early port allocation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:53:59 -0000 Hello WG! A friendly reminder to make your opinion known about early port allocation = for the signal channel as soon as possible. Regards, Roman and Tobias -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: Friday, December 08, 2017 10:27 AM To: dots@ietf.org Subject: [Dots] Consensus call for early port allocation Hello WG! The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) have = requested an early allocation of a port number from IANA per RFC7120. See = https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. To proceed, WG consensus on this allocation is required (per step 3 of Sect= ion 3.1 of RFC7120). Please provide feedback on the mailing list on this t= opic by Friday, December 15. Regards, Roman and Tobias _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 15 09:42:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0E6129409 for ; Fri, 15 Dec 2017 09:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFzo9biNem6j for ; Fri, 15 Dec 2017 09:42:50 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5A3128961 for ; Fri, 15 Dec 2017 09:42:50 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id o130so30473162itg.0 for ; Fri, 15 Dec 2017 09:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IoYxOy3vabbNIAfYW3eOxAlOrulRquMNPNkMULr1xFk=; b=TEWj79HR5bUqanagCTrnIf8MQA/Ak6jQuKMZE6qhNG2Nd25DLzfywSVBbqb75z9SzH aS3dXjWkEEX3UgmmGn31o5zfaaqd/GTICAJACgTgd4P3oo+hjKhIpYEj0BewT7VPgUZ+ 1heI2AuVurM3SYz/ZQZVIexlap7t+36GjLnbl7a3A/6NyzHU5I5wTDs/Pr0Eu/dlyv72 y69oViCyp+Z/MtsdSb9Np1xmHRvu4uJZK/gdQTP8ekvtu/ruBnSeOLpaiXqcl861e+0P bfxxi9C3pLZ1Gw3OsXulSgkw/qZKlucRdfW6UJQOuKCFVdXTzZd8IMn6tP7p1Fuw7KZD 6iOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoYxOy3vabbNIAfYW3eOxAlOrulRquMNPNkMULr1xFk=; b=fldgxG/x6l2IVJ/kdJNmUkbr+SwZAg+FoKauHXtnDyOyu28lHGN0UjK1/LM2becpDK JWz+uSPsunZX6kx47Mp/RL5et2EtAkVsk1o5fS+W7vVX0cj7vxRv3PpQXxq6Rbmp08Oi nX7hPYbd0GVD9tcw2Rwfo+oE/7ywaxAoMnA/4Y8GAurVlFjfIbNsiaGAUYW5bN3LxZhv 6/UkDkngFS1bVbbPY8rMBMqpe+VpEoGPkA+AbC3RM7+04k0tVocgScMVe2TitfEfjCCS kiWEqHntXqH4gmhfjj7TtUP68Sp9YehIUeLFpd/Kvv19TOF+80YeSUAcL1FKyWEELSQU Ebbg== X-Gm-Message-State: AKGB3mJJlX6YZ+e8pNVjrjtzDNinnZRZktxFh1BqfOnUrHkycPz36zMY dHHktzwjtcNExMw/3s5oPSExlN/IlDTD0ytrhWgdhA== X-Google-Smtp-Source: ACJfBotxzRTszZWBFjyRj7oLPdaOM7vxSuPzA8V1JoGFMjHpRFkMp0QLy7fsaMUuANgbUjS5Xd6kizovP5gAaaAJlEs= X-Received: by 10.36.131.200 with SMTP id d191mr9859221ite.97.1513359770074; Fri, 15 Dec 2017 09:42:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.111.21 with HTTP; Fri, 15 Dec 2017 09:42:49 -0800 (PST) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131347BF8@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0131347BF8@marathon> From: Jelena Mirkovic Date: Fri, 15 Dec 2017 09:42:49 -0800 Message-ID: To: Roman Danyliw Cc: "dots@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11880a835b180560648715" Archived-At: Subject: Re: [Dots] Reminder -- Consensus call for early port allocation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:42:52 -0000 --94eb2c11880a835b180560648715 Content-Type: text/plain; charset="UTF-8" Agreed ========================= Jelena Mirkovic Research Assistant Professor USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 310-448-9170 On Fri, Dec 15, 2017 at 8:53 AM, Roman Danyliw wrote: > Hello WG! > > A friendly reminder to make your opinion known about early port allocation > for the signal channel as soon as possible. > > Regards, > Roman and Tobias > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Friday, December 08, 2017 10:27 AM > To: dots@ietf.org > Subject: [Dots] Consensus call for early port allocation > > Hello WG! > > The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) > have requested an early allocation of a port number from IANA per RFC7120. > See https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. > > To proceed, WG consensus on this allocation is required (per step 3 of > Section 3.1 of RFC7120). Please provide feedback on the mailing list on > this topic by Friday, December 15. > > Regards, > Roman and Tobias > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --94eb2c11880a835b180560648715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed

<= div>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Jelena Mirkovic
Research= Assistant Professor
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170

=

On Fri, Dec 15, 2017 at 8:53 AM, Roman Danyl= iw <= rdd@cert.org> wrote:
Hello = WG!

A friendly reminder to make your opinion known about early port allocation = for the signal channel as soon as possible.

Regards,
Roman and Tobias

-----Original Message-----
From: Dots [mailto:dots-bounces@ie= tf.org] On Behalf Of Roman Danyliw
Sent: Friday, December 08, 2017 10:27 AM
To: dots@ietf.org
Subject: [Dots] Consensus call for early port allocation

Hello WG!

The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) = have requested an early allocation of a port number from IANA per RFC7120.= =C2=A0 See https://www.ietf.org/mail= -archive/web/dots/current/msg01730.html.

To proceed, WG consensus on this allocation is required (per step 3 of Sect= ion 3.1 of RFC7120).=C2=A0 Please provide feedback on the mailing list on t= his topic by Friday, December 15.

Regards,
Roman and Tobias

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--94eb2c11880a835b180560648715-- From nobody Sat Dec 16 12:28:32 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EEB1270B4 for ; Sat, 16 Dec 2017 12:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQuUxNFx2Iez for ; Sat, 16 Dec 2017 12:28:28 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE37126C89 for ; Sat, 16 Dec 2017 12:28:27 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQJ4K-000361-QT; Sat, 16 Dec 2017 20:28:24 +0000 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Sat, 16 Dec 2017 20:28:25 -0000 Message-ID: <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015C_01D376AC.6CC0BF20" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nKD1L/wQ Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 20:28:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_015C_01D376AC.6CC0BF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and will not actually help to try and solve what I perceive is the underlying issue that has triggered this discussion - "How do we handle 'client-identifiers' when a DOTS gateway does aggregation?". I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time a request or update (both signal and data) passes upstream through a DOTS gateway, an additional 'client-identifier' is added to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ | | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identification :- C1ax does a PUT [alias-name=Server1], C2x does a PUT [alias-name=Server1&client-identifer=CI(C1ax)], C3k does a PUT [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)] so that if any of the DOTS clients do a PUT [alias-name=Server1] (with same alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=Server1, by the time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=Server1, S3 will see the alias-name as [alias-name=Server1&client-identifer=CI(C1aj),CI(C2j)] and match accordingly. As responses come back from S3 to the originating client, the appropriate CI(cxxx) gets stripped off so the originating client sees no 'client-identifier' fields at all. This general solution is simple with only one disadvantage - there is a limit of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into a single UDP packet due to MTU restrictions. However in practice there are unlikely to be this number of DOTS gateways. The count varies based on how much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection - especially as different client-identifiers separate out the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation requests - but may have common information (e.g. same protocol, ports, alias-name). If the mitigation requests are not unique then we have potential conflicts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes - aggregating different port requirements for different target-prefixes gets more interesting... This adds in a lot of potential complexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then may be ordering challenges / conflicts - e.g. one filter has an IP that is a white-list, and another has the same IP as a black-list - both valid in the respective client environment. Ordering of conflicting filter information is important and I am not sure that a DOTS gateway will do this properly unless it either has some hints or complex rules to work with - just adding in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to partially resolve some of the challenges (e.g. list of client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 - 24 *-identifiers in total due to packet MTU. Even if we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 - 20. Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregation is supported? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select the appropriate policy to enforce, signal/data channel protocol drafts specify a parameter called "client-identifier". The design allows this parameter to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also cases where multiple DOTS gateways are involved. (2)Requests from multiple clients may be aggregated by the same server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. The current approach has the merit to not make any assumption on the gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such confusion. Two options are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clients, not gateways. - On-path gateways may include a new parameter called 'gateway-identifier' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=====G1====G2====S G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple gateways are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients. An example is provided below: C=====G1====G2====S G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addition to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med ------=_NextPart_000_015C_01D376AC.6CC0BF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”.  I am leaning towards your Option 2.  = Some of my reasoning is below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS = client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

         = ;            =             &= nbsp;  =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS = client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K = (C3k) -------- (S3)   

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp; |          &nb= sp;           &nbs= p;     =      

DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

so = that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 15 December 2017 = 14:20
To: dots@ietf.org
Subject: [Dots] = client-identifier: Recurisve signaling & = Aggregation

 

Hi all, =

 

To = avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called “client-identifier”. The design = allows this parameter to carry multiple values.

 

Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of = multiple values.

 

The = potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment = choices):

 

(1)Multiple gateways = may be on path. For example, draft-ietf-dots-architecture discusses = recursive signaling and also cases where multiple DOTS gateways are = involved.

(2)Requests from = multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The = current approach has the merit to not make any assumption on the gateway = behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS = server does not know whether multiple client-ids supplied in a messages = refer to multiple DOTS clients or to a DOTS client and a set of on-path = gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:

 

Option = 1 (Avoid making any assumption on gateways/proper semantic distinction = between clients and on-path gateways)

-    Restrict the usage of ‘client-identifier’ to carry = identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An = example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 = will update the request with ‘client-identifier’ pointing to = C

G2 will update the = request with ‘gateway-identifier’ pointing to = G1

 

Option = 2 (Describe what a gateway cannot do)

-    Update = the architecture document to indicate that requests are not aggregated = by a dots gateway.

-    ‘client-identifier’ includes multiple values only and = only if multiple gateways are on-path. The order of the values is = important because the first one will be the one pointing to the source = DOTS clients.

 

An = example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 = will update the request with ‘client-identifier’ pointing to = C

G2 will update the = request with ‘client-identifier’ pointing to G1 (in addition = to C)

 

We are = seeking for feedback from the WG on which direction to take. =

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_015C_01D376AC.6CC0BF20-- From nobody Sun Dec 17 09:17:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C40B127137 for ; Sun, 17 Dec 2017 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0pM8Yt4cq6U for ; Sun, 17 Dec 2017 09:17:14 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632AF126D74 for ; Sun, 17 Dec 2017 09:17:14 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id f2so17539904qtj.4 for ; Sun, 17 Dec 2017 09:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=04YBeGDnjx5nPNurv8TEcECJiYm5dimCtlasnjGbk+g=; b=Dw5Ybu/gsciQXX/evhq+eWDwrAXnkJwctr7CQxqUDhnnJOnvHPE9gVLMnwhnuErSLP sH+83C/YK/Q+A2wyj5+i6KsItDbVsDnq9u1n54gHhpjqAvrEYPxB3mK/niIfPPzwjL3g X7QaAvai4BP+AfcjA1HDagTDwNp7m91KUHA+/rO1GrXEJsgSwigNVQkzPj8I8ZghdPE5 xsGcN8Y7QsPAHvix+BmQnzRZ4tCWxBTZolpk7lgIfqFt380vD4Hw44anREn2WH7v0IpF bfI/M8hQcnH7QtDg4ri41y39C5eCMpR+F+rN+m2+wdOyZjRgvvYcTgs8JlUEwxdx03K8 QyGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=04YBeGDnjx5nPNurv8TEcECJiYm5dimCtlasnjGbk+g=; b=C82yVHb1Rvqc4GEu+NqSjqRz6i5uA8q1s+qYwncn3ApA1XO5/2Da0r3cGpEGU/4fSk Qm4m1NVqQi3jhdCxI9I8q91nCv5m1c/GfGi1+aMKH9dOriSbd6UGF8PemzJjsZV6B/y8 H13GalK0mFuXjHpEKH0Ojn+zr7+JaqHpjQnjK+nfs4IPGtPnxXBovqeRZw2X/fVQkWPH MMRfqZLj2V+ab5LyHJAhjgjfySFqB3BzI/VC3b1I2J7+JlrbXDnHqdEKtxQIWTgGHayd wqz7scbNw6zbEnnJU54yDPc5/8WcU02/t7OUZWlBhTFZPYnKsAwiZtDpqiSOX5Z48tUw 1LDw== X-Gm-Message-State: AKGB3mKUUxsUZAqE7chnsAXG8S/eljSFr+0NXeCskUaFI/OiNFLClCPN 7XmozVnYoMBB/j3aewxDjTg+5B0UK8v/1bDrbFE= X-Google-Smtp-Source: ACJfBotE5e9ugfsDnURVy2xdx2koC3/SZGJVrClgCZYdgKp7J9kgbkna2kQ2PogoLuVduODtR4zaKvABXwVznZf9U8I= X-Received: by 10.237.63.233 with SMTP id w38mr31492079qth.213.1513531033312; Sun, 17 Dec 2017 09:17:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.68 with HTTP; Sun, 17 Dec 2017 09:17:12 -0800 (PST) Received: by 10.12.161.68 with HTTP; Sun, 17 Dec 2017 09:17:12 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Chiheb Chebbi Date: Sun, 17 Dec 2017 18:17:12 +0100 Message-ID: To: mohamed.boucadair@orange.com Cc: dots@ietf.org Content-Type: multipart/alternative; boundary="001a1146617898e63605608c6722" Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 17:17:16 -0000 --001a1146617898e63605608c6722 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I hope you are doing well.I am a security enthusiast from Tunisia.I am new here, I started reading the drafts and what are you doing is great.I am wondering if there are some implementations of DOTS (use cases, code snippets, maybe some clients and servers prototypes etc...) Or is it too early for a technical implementation? Thank you so much! Kind regards, Chiheb On Dec 15, 2017 3:19 PM, wrote: > Hi all, > > > > To avoid potential conflicts and also in order to help the server select > the appropriate policy to enforce, signal/data channel protocol drafts > specify a parameter called =E2=80=9Cclient-identifier=E2=80=9D. The desig= n allows this > parameter to carry multiple values. > > > > Putting aside the extensibility argument of the data model, the > signal/data channel protocol drafts are silent about the exact use of > multiple values. > > > > The potential deployment cases for multiple values are (without making an= y > assumption whether these cases are good/bad deployment choices): > > > > (1)Multiple gateways may be on path. For example, > draft-ietf-dots-architecture discusses recursive signaling and also cases > where multiple DOTS gateways are involved. > > (2)Requests from multiple clients may be aggregated by the same > server-side into one single request forwarded to the upstream server. For > example, filtering rules received from multiple clients of the same domai= n > may be aggregated in one single request. > > > > The current approach has the merit to not make any assumption on the > gateway behavior (e.g., (2)), but it leads to a confusion. For example, a > DOTS server does not know whether multiple client-ids supplied in a > messages refer to multiple DOTS clients or to a DOTS client and a set of > on-path gateways. The protocol documents need to be updated to avoid such > confusion. Two options are listed below: > > > > Option 1 (Avoid making any assumption on gateways/proper semantic > distinction between clients and on-path gateways) > > - Restrict the usage of =E2=80=98client-identifier=E2=80=99 to carry i= dentifiers of > clients, not gateways. > > - On-path gateways may include a new parameter called > =E2=80=98gateway-identifier=E2=80=99 to ease contexts retrieval and avoid= potential > collisions. > > > > An example is provided below: > > > > C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG1=3D=3D=3D=3DS > > > > G1 will update the request with =E2=80=98client-identifier=E2=80=99 point= ing to C > > G2 will update the request with =E2=80=98gateway-identifier=E2=80=99 poin= ting to G1 > > > > Option 2 (Describe what a gateway cannot do) > > - Update the architecture document to indicate that requests are not > aggregated by a dots gateway. > > - =E2=80=98client-identifier=E2=80=99 includes multiple values only an= d only if > multiple gateways are on-path. The order of the values is important becau= se > the first one will be the one pointing to the source DOTS clients. > > > > An example is provided below: > > > > C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG1=3D=3D=3D=3DS > > > > G1 will update the request with =E2=80=98client-identifier=E2=80=99 point= ing to C > > G2 will update the request with =E2=80=98client-identifier=E2=80=99 point= ing to G1 (in > addition to C) > > > > We are seeking for feedback from the WG on which direction to take. > > > > Thoughts? > > > > Cheers, > > Med > > > > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > --001a1146617898e63605608c6722 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
I hope you are doing well.I am a= security enthusiast from Tunisia.I am new here, I started reading the draf= ts and what are you doing is great.I am wondering if there are some impleme= ntations of DOTS (use cases, code snippets, maybe some clients and servers = prototypes etc...) Or is it too early for a technical implementation? Thank= you so much!

Kind regar= ds,
Chiheb
On Dec 15, 2017 3:19 PM, <mohamed.boucadair@orange.com> wrote:<= br type=3D"attribution">

Hi all,

=C2=A0

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called =E2=80=9Cclient-identifier=E2=80=9D. The design allows this paramet= er to carry multiple values.

=C2=A0

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

=C2=A0

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

=C2=A0

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request. =C2=A0=C2=A0

=C2=A0

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

=C2=A0

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

-= =C2=A0=C2=A0=C2=A0 Restrict the usage o= f =E2=80=98client-identifier=E2=80=99 to carry identifiers of clients, not = gateways.

-= =C2=A0=C2=A0=C2=A0 On-path gateways may= include a new parameter called =E2=80=98gateway-identifier=E2=80=99 to eas= e contexts retrieval and avoid potential collisions.

=C2=A0

An example is provided be= low:

=C2=A0

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG1=3D=3D=3D=3DS

=C2=A0

G1 will update the reques= t with =E2=80=98client-identifier=E2=80=99 pointing to C

G2 will update the reques= t with =E2=80=98gateway-identifier=E2=80=99 pointing to G1

=C2=A0

Option 2 (Describe what a= gateway cannot do)

-= =C2=A0=C2=A0=C2=A0 Update the architect= ure document to indicate that requests are not aggregated by a dots gateway= .

-= =C2=A0=C2=A0=C2=A0 =E2=80=98client-iden= tifier=E2=80=99 includes multiple values only and only if multiple gateways= are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

=C2=A0

An example is provided be= low:

=C2=A0

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG1=3D=3D=3D=3DS

=C2=A0

G1 will update the reques= t with =E2=80=98client-identifier=E2=80=99 pointing to C

G2 will update the reques= t with =E2=80=98client-identifier=E2=80=99 pointing to G1 (in addition to C= )

=C2=A0

We are seeking for feedba= ck from the WG on which direction to take.

=C2=A0

Thoughts?

=C2=A0

Cheers,

Med<= /p>

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a1146617898e63605608c6722-- From nobody Sun Dec 17 15:16:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6526126BF0 for ; Sun, 17 Dec 2017 15:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyIzDz4JytIq for ; Sun, 17 Dec 2017 15:16:12 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E0C124234 for ; Sun, 17 Dec 2017 15:16:12 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vBHNG9LG026804; Sun, 17 Dec 2017 18:16:09 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu vBHNG9LG026804 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1513552569; bh=k0X/fIyT6DITFA4JAabyBXR+wEekT89rbA+IoXhNwGE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=cyxHD8Qhi8kNFuzXvJtsfv4uLbskDvToLP0BMwxr+mBgOf6Yq5rCAWNMhDRqdgV5D sh/Lhw29yIIRy4K5Wi7/mVAfewSISIlMgQqY2W6OsVurI9rmMwWBA1TdrfJaZV49Wl ds5IkEmD76dil42i01W+hkhueNNb9RZ8c0Fde4H4= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vBHNG77B001072; Sun, 17 Dec 2017 18:16:07 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Sun, 17 Dec 2017 18:16:06 -0500 From: Roman Danyliw To: Chiheb Chebbi CC: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowB1QgsAAAIOkMw= Date: Sun, 17 Dec 2017 23:16:05 +0000 Message-ID: <270C85AD-CA7C-4974-93BD-B8487CAACCA2@cert.org> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_270C85ADCA7C497493BDB8487CAACCA2certorg_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 23:16:15 -0000 --_000_270C85ADCA7C497493BDB8487CAACCA2certorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Chiheb! There are a few implementations of DOTS. The following page provides pointe= rs to them and to a public test server: https://trac.ietf.org/trac/dots To read more about use cases see: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ If you have any feedback on what you find, please let us know. Roman On Dec 17, 2017, at 12:17, Chiheb Chebbi > wrote: Hi all, I hope you are doing well.I am a security enthusiast from Tunisia.I am new = here, I started reading the drafts and what are you doing is great.I am won= dering if there are some implementations of DOTS (use cases, code snippets,= maybe some clients and servers prototypes etc...) Or is it too early for a= technical implementation? Thank you so much! Kind regards, Chiheb On Dec 15, 2017 3:19 PM, > wrote: Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called =93client-identifier=94. The design allows this parame= ter to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers of = clients, not gateways. - On-path gateways may include a new parameter called =91gateway-identif= ier=92 to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG1=3D=3D=3D=3DS G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if mult= iple gateways are on-path. The order of the values is important because the= first one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG1=3D=3D=3D=3DS G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 (in = addition to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_270C85ADCA7C497493BDB8487CAACCA2certorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Chiheb!

There are a few implementations of DOTS. The following page provides p= ointers to them and to a public test server:


To read more about use cases see:


If you have any feedback on what you find, please let us know.

Roman

On Dec 17, 2017, at 12:17, Chiheb Chebbi <chiheb.chebbi2015@gmail.com> wrote:

Hi all,
I hope you are doing well.I am a security enthusiast from= Tunisia.I am new here, I started reading the drafts and what are you doing= is great.I am wondering if there are some implementations of DOTS (use cas= es, code snippets, maybe some clients and servers prototypes etc...) Or is it too early for a technical implemen= tation? Thank you so much!

Kind regards,
Chiheb

On Dec 15, 2017 3:19 PM, <mohamed.boucadair@orange.com> wrote:

Hi all,

 

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called =93client-identifier=94. The design allows this parameter to carry = multiple values.

 

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discusses recurs= ive signaling and also cases where multiple DOTS gateways are involved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one single= request forwarded to the upstream server. For example, filtering rules rec= eived from multiple clients of the same domain may be aggregated in one sin= gle request.   

 

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

-&n= bsp;   Restrict the usage o= f =91client-identifier=92 to carry identifiers of clients, not gateways.

-&n= bsp;   On-path gateways may= include a new parameter called =91gateway-identifier=92 to ease contexts r= etrieval and avoid potential collisions.

 

An example is provided be= low:

 

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG1=3D=3D=3D=3DS

 

G1 will update the reques= t with =91client-identifier=92 pointing to C

G2 will update the reques= t with =91gateway-identifier=92 pointing to G1

 

Option 2 (Describe what a= gateway cannot do)

-&n= bsp;   Update the architect= ure document to indicate that requests are not aggregated by a dots gateway= .

-&n= bsp;   =91client-identifier= =92 includes multiple values only and only if multiple gateways are on-path= . The order of the values is important because the first one will be the one pointing to the source DOTS clients. =

 

An example is provided be= low:

 

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG1=3D=3D=3D=3DS

 

G1 will update the reques= t with =91client-identifier=92 pointing to C

G2 will update the reques= t with =91client-identifier=92 pointing to G1 (in addition to C)<= /u>

 

We are seeking for feedba= ck from the WG on which direction to take.

 

Thoughts?

 

Cheers,

Med<= /p>

 

 

 


_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ie= tf.org/mailman/listinfo/dots
--_000_270C85ADCA7C497493BDB8487CAACCA2certorg_-- From nobody Sun Dec 17 17:30:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237FD1241FC for ; Sun, 17 Dec 2017 17:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMty4NfbE48J for ; Sun, 17 Dec 2017 17:30:47 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6C51200C5 for ; Sun, 17 Dec 2017 17:30:46 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id C767525F692; Mon, 18 Dec 2017 10:30:43 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 3A8197634FC; Mon, 18 Dec 2017 10:30:43 +0900 (JST) To: Jon Shallow , mohamed.boucadair@orange.com, dots@ietf.org References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> From: kaname nishizuka Message-ID: Date: Mon, 18 Dec 2017 10:30:47 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------4E8E6C38D8AF7EB5FEDABD78" Content-Language: en-US Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 01:30:50 -0000 This is a multi-part message in MIME format. --------------4E8E6C38D8AF7EB5FEDABD78 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, > The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel. In order to accomplish this, we need to exclude any chance of seeing non unique client-identifier from a view point of the final DOTS server. in the latest draft: The client-identifier attribute SHOULD NOT be       generated and included by the DOTS client. I propose making it "MUST NOT": The client-identifier attribute MUST NOT be       generated and included by the DOTS client. or adding the text like this: The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. If a client-identifier was generated by the DOTS client, the DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients. thanks, Kaname On 2017/12/17 5:28, Jon Shallow wrote: > > Hi Med and all, > > I think that ‘gateway-identifier’ is likely to cause more confusion and will not actually help to try and solve what I perceive is the underlying issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggregation?”.  I am leaning towards your Option 2. Some of my reasoning is below. > > *Background to client-identifiers.* > > In the general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time a request or update (both signal and data) passes upstream through a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel. > > Client Identification Usage Example > > DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ > > DOTS client (C1bj) ----------------------------------------/                | > >                                                           | > > DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3) > > DOTS client (C1bx) --------/                               | > >                                                            | > > DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ > > DOTS client (C1by) --------/ > > Where CI is ‘client-identifier’ – a unique hash of the client identification :- > > C1ax does a PUT [alias-name=Server1], > > C2x does a PUT [alias-name=Server1&client-identifer=CI(C1ax)], > > C3k does a PUT [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x)] > > and then S3 uniquely stores this alias-name as [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)] > > so that if any of the DOTS clients do a PUT [alias-name=Server1] (with same alias name) S3 can differentiate them all based on the different CI(). > > Then when C1ax requests a mitigation with alias-name=Server1, by the time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]. > > If C1aj also requests a mitigation with alias-name=Server1, S3 will see the alias-name as [alias-name=Server1&client-identifer=CI(C1aj),CI(C2j)] and match accordingly. > > As responses come back from S3 to the originating client, the appropriate CI(cxxx) gets stripped off so the originating client sees no ‘client-identifier’ fields at all. > > This general solution is simple with only one disadvantage – there is a limit of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.  The count varies based on how much other information needs to be put into the packet. > > *DOTS Gateway Session aggregation* > > There is no reason as to why multiple DOTS clients’ signal and data requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection – especially as different client-identifiers separate out the different requests / responses. > > This session aggregation is not the same as signal / data aggregation > > NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may be where some of the confusion comes in) > > Figure 7: Client-Side Gateway with session Aggregation > > Figure 8: Client-Side Gateway without session Aggregation > > Figure 9: Server-Side Gateway with session Aggregation > > Figure 10: Server-Side Gateway without session Aggregation > > *DOTS Gateway signal / data aggregation challenges* > > Individual clients in general will generate their unique mitigation requests – but may have common information (e.g. same protocol, ports, alias-name).  If the mitigation requests are not unique then we have potential conflicts – not part of this discussion. > > Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..  This adds in a lot of potential complexity with potential for boundary condition error issues. > > Aggregation of Filters is at first sight relatively simple - but there then may be ordering challenges / conflicts – e.g. one filter has an IP that is a white-list, and another has the same IP as a black-list – both valid in the respective client environment.  Ordering of conflicting filter information is important  and I am not sure that a DOTS gateway will do this properly unless it either has some hints or complex rules to work with – just adding in complexity where more things can potentially go wrong. > > Use of gateway-identifier and client-identifier combination can be used to partially resolve some of the challenges (e.g. list of client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total due to packet MTU.  Even if we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregation is supported? > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *mohamed.boucadair@orange.com > *Sent:* 15 December 2017 14:20 > *To:* dots@ietf.org > *Subject:* [Dots] client-identifier: Recurisve signaling & Aggregation > > Hi all, > > To avoid potential conflicts and also in order to help the server select the appropriate policy to enforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter to carry multiple values. > > Putting aside the extensibility argument of the data model, the signal/data channel protocol drafts are silent about the exact use of multiple values. > > The potential deployment cases for multiple values are (without making any assumption whether these cases are good/bad deployment choices): > > (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also cases where multiple DOTS gateways are involved. > > (2)Requests from multiple clients may be aggregated by the same server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. > > The current approach has the merit to not make any assumption on the gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such confusion. Two options are listed below: > > Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) > > -Restrict the usage of ‘client-identifier’ to carry identifiers of clients, not gateways. > > -On-path gateways may include a new parameter called ‘gateway-identifier’ to ease contexts retrieval and avoid potential collisions. > > An example is provided below: > > C=====G1====G2====S > > G1 will update the request with ‘client-identifier’ pointing to C > > G2 will update the request with ‘gateway-identifier’ pointing to G1 > > Option 2 (Describe what a gateway cannot do) > > -Update the architecture document to indicate that requests are not aggregated by a dots gateway. > > -‘client-identifier’ includes multiple values only and only if multiple gateways are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients. > > An example is provided below: > > C=====G1====G2====S > > G1 will update the request with ‘client-identifier’ pointing to C > > G2 will update the request with ‘client-identifier’ pointing to G1 (in addition to C) > > We are seeking for feedback from the WG on which direction to take. > > Thoughts? > > Cheers, > > Med > > __ > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------4E8E6C38D8AF7EB5FEDABD78 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,


> The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel.

In order to accomplish this, we need to exclude any chance of seeing non unique client-identifier from a view point of the final DOTS server.


in the latest draft:
The client-identifier attribute SHOULD NOT be
      generated and included by the DOTS client.

I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be
      generated and included by the DOTS client.

or adding the text like this:

The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. If a client-identifier was generated by the DOTS client, the DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.


thanks,
Kaname
On 2017/12/17 5:28, Jon Shallow wrote:

Hi Med and all,

 

I think that ‘gateway-identifier’ is likely to cause more confusion and will not actually help to try and solve what I perceive is the underlying issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggregation?”.  I am leaning towards your Option 2.  Some of my reasoning is below.

 

Background to client-identifiers.

 

In the general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time a request or update (both signal and data) passes upstream through a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, say, an (possibly non unique alias-name) alias definition sent over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent over the signal channel.

 

Client Identification Usage Example

 

DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ----------\  

DOTS client (C1bj) ----------------------------------------/                                  |

                                                                                              |

DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)   

DOTS client (C1bx) --------/                               |                               

                                                           |                                 

DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/                                 

DOTS client (C1by) --------/                                                                   

 

Where CI is ‘client-identifier’ – a unique hash of the client identification :-

C1ax does a PUT [alias-name=Server1],

C2x does a PUT [alias-name=Server1&client-identifer=CI(C1ax)],

C3k does a PUT [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x)]

and then S3 uniquely stores this alias-name as [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)]

so that if any of the DOTS clients do a PUT [alias-name=Server1] (with same alias name) S3 can differentiate them all based on the different CI().

 

Then when C1ax requests a mitigation with alias-name=Server1, by the time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=Server1&client-identifer=CI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a mitigation with alias-name=Server1, S3 will see the alias-name as [alias-name=Server1&client-identifer=CI(C1aj),CI(C2j)] and match accordingly.

 

As responses come back from S3 to the originating client, the appropriate CI(cxxx) gets stripped off so the originating client sees no ‘client-identifier’ fields at all.

 

This general solution is simple with only one disadvantage – there is a limit of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.  The count varies based on how much other information needs to be put into the packet.

 

DOTS Gateway Session aggregation

 

There is no reason as to why multiple DOTS clients’ signal and data requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection – especially as different client-identifiers separate out the different requests / responses.

 

This session aggregation is not the same as signal / data aggregation

 

NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may be where some of the confusion comes in)

Figure 7: Client-Side Gateway with session Aggregation

Figure 8: Client-Side Gateway without session Aggregation

Figure 9: Server-Side Gateway with session Aggregation

Figure 10: Server-Side Gateway without session Aggregation

 

 

DOTS Gateway signal / data aggregation challenges

 

Individual clients in general will generate their unique mitigation requests – but may have common information (e.g. same protocol, ports, alias-name).  If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.

 

Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..  This adds in a lot of potential complexity with potential for boundary condition error issues.

 

Aggregation of Filters is at first sight relatively simple - but there then may be ordering challenges / conflicts – e.g. one filter has an IP that is a white-list, and another has the same IP as a black-list – both valid in the respective client environment.  Ordering of conflicting filter information is important  and I am not sure that a DOTS gateway will do this properly unless it either has some hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

 

Use of gateway-identifier and client-identifier combination can be used to partially resolve some of the challenges (e.g. list of client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total due to packet MTU.  Even if we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregation is supported?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the server select the appropriate policy to enforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter to carry multiple values.

 

Putting aside the extensibility argument of the data model, the signal/data channel protocol drafts are silent about the exact use of multiple values.

 

The potential deployment cases for multiple values are (without making any assumption whether these cases are good/bad deployment choices):

 

(1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also cases where multiple DOTS gateways are involved.

(2)Requests from multiple clients may be aggregated by the same server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request.   

 

The current approach has the merit to not make any assumption on the gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such confusion. Two options are listed below:

 

Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways)

-    Restrict the usage of ‘client-identifier’ to carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called ‘gateway-identifier’ to ease contexts retrieval and avoid potential collisions.

 

An example is provided below:

 

C=====G1====G2====S

 

G1 will update the request with ‘client-identifier’ pointing to C

G2 will update the request with ‘gateway-identifier’ pointing to G1

 

Option 2 (Describe what a gateway cannot do)

-    Update the architecture document to indicate that requests are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values only and only if multiple gateways are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 

An example is provided below:

 

C=====G1====G2====S

 

G1 will update the request with ‘client-identifier’ pointing to C

G2 will update the request with ‘client-identifier’ pointing to G1 (in addition to C)

 

We are seeking for feedback from the WG on which direction to take.

 

Thoughts?

 

Cheers,

Med

 

 

 



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------4E8E6C38D8AF7EB5FEDABD78-- From nobody Sun Dec 17 22:59:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3CE12704B for ; Sun, 17 Dec 2017 22:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXCUi1mNhKee for ; Sun, 17 Dec 2017 22:59:25 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1222F12711B for ; Sun, 17 Dec 2017 22:59:25 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 728651007FF; Mon, 18 Dec 2017 07:59:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 50C836006C; Mon, 18 Dec 2017 07:59:23 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 07:59:22 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowA9EmaAAEksXYA= Date: Mon, 18 Dec 2017 06:59:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> In-Reply-To: <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A099D30OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 06:59:28 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A099D30OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). I do see some implications of this design in a multi-homing scenario with t= he same mitigation provider: the same request from a multi-homed DOTS clien= t will be presented to the server as being distinct requests...while this i= s not. It may be the same request that is forked among existent network att= achments or a request that is sent over a first link, but a subsequent one = over another link. Separating both client-id from gateway-id does not suffer from this issue (= even when no aggregation). so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A099D30OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thank you for= sharing your thoughts.

 

Please see co= mments inline.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There a= re also some complications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client = (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ---= -------\  

DOTS client = (C1bj) ----------------------------------------/    &nb= sp;            =              &n= bsp;   |

  =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

DOTS client = (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) ---= ----- (S3)   

DOTS client = (C1bx) --------/          = ;            &n= bsp;        |   &nbs= p;            &= nbsp;            &nb= sp; 

  =             &nb= sp;            =             &nb= sp;            =        |     &n= bsp;            = ;             &= nbsp; 

DOTS client = (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/    &nb= sp;            =              &n= bsp;  

DOTS client = (C1by) --------/          = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This as= sumes that the DOTS forwarding path will always be the same (that is, the s= ame set of gateways will be solicited for requests coming from a given DOTS client).

 

I do see some= implications of this design in a multi-homing scenario with the same mitig= ation provider: the same request from a multi-homed DOTS client will be presented to the server as being distinct requests…while thi= s is not. It may be the same request that is forked among existent network = attachments or a request that is sent over a first link, but a subsequent o= ne over another link.

 

Separating bo= th client-id from gateway-id does not suffer from this issue (even when no = aggregation).    

 

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess= you meant “restrict the number of aggregated clients per DOTS gatewa= y”, not the “number of DOTS clients serviced by a DOTS gateway&= #8221;. I would say this is deployment-specific. A deployment that enables signal/= data channel aggregation is aware of this limitation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

- = ;   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

- = ;   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A099D30OPEXCLILMA3corp_-- From nobody Sun Dec 17 23:12:43 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0719412711B for ; Sun, 17 Dec 2017 23:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLo53okKhqdE for ; Sun, 17 Dec 2017 23:12:39 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC91126CC4 for ; Sun, 17 Dec 2017 23:12:38 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id BAB6A601EC; Mon, 18 Dec 2017 08:12:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 94BD040065; Mon, 18 Dec 2017 08:12:36 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 08:12:23 +0100 From: To: kaname nishizuka , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowA9EmaAADzZ+YAADauLcA== Date: Mon, 18 Dec 2017 07:12:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A099D58@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A099D58OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 07:12:42 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A099D58OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kaname, =AB s/SHOULD NOT/MUST NOT =BB works for me. The issue discussed in this thread is still open, though. Cheers, Med De : kaname nishizuka [mailto:kaname@nttv6.jp] Envoy=E9 : lundi 18 d=E9cembre 2017 02:31 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi, > The final DOTS server can then uniquely identify the request / update as = coming from a specific Client and exactly match, say, an (possibly non uniq= ue alias-name) alias definition sent over the data channel with a (possibly= non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel. In order to accomplish this, we need to exclude any chance of seeing non un= ique client-identifier from a view point of the final DOTS server. in the latest draft: The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client. or adding the text like this: The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value = among different DOTS clients. thanks, Kaname On 2017/12/17 5:28, Jon Shallow wrote: Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?". I am leaning towards your Optio= n 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1) Multiple gateways may be on path. For example, draft-ietf-dots-ar= chitecture discusses recursive signaling and also cases where multiple DOTS= gateways are involved. (2) Requests from multiple clients may be aggregated by the same serv= er-side into one single request forwarded to the upstream server. For examp= le, filtering rules received from multiple clients of the same domain may b= e aggregated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clien= ts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifier= ' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggr= egated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple = gateways are on-path. The order of the values is important because the firs= t one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_787AE7BB302AE849A7480A190F8B93300A099D58OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kaname,=

 

=AB s/SH= OULD NOT/MUST NOT =BB works for me.

 

The issue dis= cussed in this thread is still open, though.

 

Cheers,

Med

 

De : 

Hi,


> The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and exactly = match, say, an (possibly non unique alias-name) alias definition sent over = the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sent ov= er the signal channel.

In order to accomplish this, we need to exclude any chance of seeing non un= ique client-identifier from a view point of the final DOTS server.


in the latest draft:
The client-identifier attribute SHOULD NOT be
      generated and included by the DOTS client.
I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.
or adding the text like this:

The client-identifier attribute SHOULD NOT be= generated and included by the DOTS client. If a client-identifier was gene= rated by the DOTS client, the DOTS gateway MUST update the value with zero = probability of the same value among different DOTS clients.


thanks,
Kaname

On 2017/12/17 5:28, Jon Shallow wrote:

Hi Med and all,=

 

I think that ‘ga= teway-identifier’ is likely to cause more confusion and will not actu= ally help to try and solve what I perceive is the underlying issue that has= triggered this discussion - “How do we handle ‘client-identifi= ers’ when a DOTS gateway does aggregation?”.  I am leaning towards y= our Option 2.  Some of my reasoning is below.

 

Background to clien= t-identifiers.

 

In the general case (e= .g. no DOTS gateway aggregation of filters / aliases etc.), every time a re= quest or update (both signal and data) passes upstream through a DOTS gatew= ay, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) -------= ------------------------------ (S1j) DOTS gateway J (C2j) ----------\ =  

DOTS client (C1bj) -------= ---------------------------------/       = ;             &= nbsp;           &nbs= p; |

    &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; |

DOTS client (C1ax) ----- (= S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)&nbs= p;  

DOTS client (C1bx) -------= -/            &= nbsp;           &nbs= p;      |      =             &nb= sp;            

    &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    |       &nbs= p;            &= nbsp;            

DOTS client (C1ay) ----- (= S1y) DOTS gateway Y (C2y) -------/       = ;            &n= bsp;            &nbs= p;

DOTS client (C1by) -------= -/            &= nbsp;           &nbs= p;             =             &nb= sp;            =     

 

Where CI is ‘cli= ent-identifier’ – a unique hash of the client identification :-=

C1ax does a PUT [alias= -name=3DServer1],

C2x does a PUT [alias-= name=3DServer1&client-identifer=3DCI(C1ax)],

C3k does a PUT [alias-= name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]

and then S3 uniquely s= tores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 can = differentiate them all based on the different CI().

 

Then when C1ax request= s a mitigation with alias-name=3DServer1, by the time the request gets to S= 3, S3 can match the alias-name definition in the mitigate request with that= of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].=

 

If C1aj also requests = a mitigation with alias-name=3DServer1, S3 will see the alias-name as [alia= s-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match accordi= ngly.

 

As responses come back= from S3 to the originating client, the appropriate CI(cxxx) gets stripped = off so the originating client sees no ‘client-identifier’ field= s at all.

 

This general solution = is simple with only one disadvantage – there is a limit of 20 - 24 cl= ient-identifiers (20 – 24 DOTS gateways) that will fit into a single = UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.  The = count varies based on how much other information needs to be put into the p= acket.

 

DOTS Gateway Sessio= n aggregation

 

There is no reason as = to why multiple DOTS clients’ signal and data requests cannot be mult= iplexed into a single session on the DOTS gateway to DOTS server connection= – especially as different client-identifiers separate out the different requests / responses.

 

This session aggregati= on is not the same as signal / data aggregation

 

NOTE: ietf-dots-archit= ecture Figure 7, 8, 9 and 10 should really read (which may be where some of= the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side= Gateway without session Aggregation

 

 

DOTS Gateway signal= / data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may have= common information (e.g. same protocol, ports, alias-name).  If the m= itigation requests are not unique then we have potential conflicts – not part of this discussion.=

 

Aggregating (unique) m= itigation requests on a DOTS gateway could be a programmatic challenge, unl= ess it is the simple aggregation of all the different target-prefixes ̵= 1; aggregating different port requirements for different target-prefixes gets more interesting…..  This ad= ds in a lot of potential complexity with potential for boundary condition e= rror issues.

 

Aggregation of Filters= is at first sight relatively simple - but there then may be ordering chall= enges / conflicts – e.g. one filter has an IP that is a white-list, a= nd another has the same IP as a black-list – both valid in the respective client environment.  Ordering of= conflicting filter information is important  and I am not sure that a= DOTS gateway will do this properly unless it either has some hints or comp= lex rules to work with – just adding in complexity where more things can potentially go wrong.

 

Use of gateway-identif= ier and client-identifier combination can be used to partially resolve some= of the challenges (e.g. list of client-identifiers that are allowed to use= this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total due to packet MTU.&= nbsp; Even if we for example say that there is a maximum of 4 DOTS gateways= allowed, we then limit the number of clients that can be aggregated to 16 = – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregation is supported?

 

Regards

 

Jon<= /p>

 

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)      = ; Multiple gateways= may be on path. For example, draft-ietf-dots-architecture discusses recurs= ive signaling and also cases where multiple DOTS gateways are involved.

(2)      = ; Requests from mul= tiple clients may be aggregated by the same server-side into one single req= uest forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated = in one single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

-   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

-   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

-   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

-   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 <= /p> 




__________________________________=
_____________
Dots mailing list
D=
ots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 <= /o:p>

--_000_787AE7BB302AE849A7480A190F8B93300A099D58OPEXCLILMA3corp_-- From nobody Mon Dec 18 02:40:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEACA127868 for ; Mon, 18 Dec 2017 02:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn2E_R75-c7x for ; Mon, 18 Dec 2017 02:39:59 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B1F126BFD for ; Mon, 18 Dec 2017 02:39:58 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQspr-0004C3-9I; Mon, 18 Dec 2017 10:39:51 +0000 From: "Jon Shallow" To: , , "kaname nishizuka" References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 18 Dec 2017 10:39:52 -0000 Message-ID: <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022A_01D377EC.89780DD0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nANCop6fAX9a7Vmg0d1E4A== Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 10:40:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022A_01D377EC.89780DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med / Kaname, =20 =93I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client.=94 We do need to handle the case of a broken client (how does the DOTS = server know it is a DOTS gateway client or a real DOTS client?) who does not = obey the MUST. =20 =93The client-identifier attribute SHOULD NOT be generated and included = by the DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.=94 =20 Is the safer option for me. =20 Otherwise, see [Jon] inline (8 times). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Thank you for sharing your thoughts.=20 =20 Please see comments inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med and all, =20 I think that =91gateway-identifier=92 is likely to cause more confusion = and will not actually help to try and solve what I perceive is the underlying = issue that has triggered this discussion - =93How do we handle = =91client-identifiers=92 when a DOTS gateway does aggregation?=94 [Med] There are also some complications even when no aggregation is in = use. See below.=20 =20 . I am leaning towards your Option 2. Some of my reasoning is below. =20 Background to client-identifiers. =20 In the general case (e.g. no DOTS gateway aggregation of filters / = aliases etc.), every time a request or update (both signal and data) passes = upstream through a DOTS gateway, an additional =91client-identifier=92 is added = to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, = say, an (possibly non unique alias-name) alias definition sent over the data = channel with a (possibly non unique mitigation-id) mitigation request using the = same alias-name sent over the signal channel. =20 Client Identification Usage Example =20 DOTS client (C1aj) ------------------------------------- (S1j) DOTS = gateway J (C2j) ----------\ =20 DOTS client (C1bj) ----------------------------------------/ | =20 | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS = gateway K (C3k) -------- (S3) =20 DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ =20 Where CI is =91client-identifier=92 =96 a unique hash of the client = identification :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)] =20 [Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client). =20 [Jon] The current text states =93If the 'client-identifier' value is = already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list.=94 =20 [Jon] The MAY is not a MUST for the simple reason that if the original = DOTS client client-identifier is computed correctly, it should be unique all = the way through the different DOTS gateways (so no additional = client-identifiers need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C1ax)]. The DOTS gateways = in the path can then change over time with no issues. =20 [Jon] All that is required then is that a DOTS gateway makes sure that = any Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional client-identifiers = (but still adds in the first one if the first DOTS gateway). =20 [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier = =96 even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information. =20 [Med]I do see some implications of this design in a multi-homing = scenario with the same mitigation provider: the same request from a multi-homed = DOTS client will be presented to the server as being distinct = requests=85while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a = subsequent one over another link. =20 [Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) = in which case the client-identifier (which is not IP based) would be the = same over the different network interfaces. =20 =20 [Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, = and hence different client-identifiers propagating up to the DOTS servers = =96 but as these are different provider domains will they ever join up into a = common domain? If they do, then this is where you could be getting conflicting requests =96 subject of another discussion. =20 [Med] Separating both client-id from gateway-id does not suffer from = this issue (even when no aggregation). =20 =20 [Jon] Yes =96 the assumption being that all the client-identifiers are = unique =96 In which case I argue again that additional information =96 e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above). =20 so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different CI(). =20 Then when C1ax requests a mitigation with alias-name=3DServer1, by the = time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]. =20 If C1aj also requests a mitigation with alias-name=3DServer1, S3 will = see the alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] = and match accordingly. =20 As responses come back from S3 to the originating client, the = appropriate CI(cxxx) gets stripped off so the originating client sees no =91client-identifier=92 fields at all. =20 This general solution is simple with only one disadvantage =96 there is = a limit of 20 - 24 client-identifiers (20 =96 24 DOTS gateways) that will = fit into a single UDP packet due to MTU restrictions. However in practice = there are unlikely to be this number of DOTS gateways. The count varies based = on how much other information needs to be put into the packet. =20 DOTS Gateway Session aggregation =20 There is no reason as to why multiple DOTS clients=92 signal and data = requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection =96 especially as different client-identifiers = separate out the different requests / responses. =20 This session aggregation is not the same as signal / data aggregation =20 NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation =20 [Med] Agree.=20 =20 DOTS Gateway signal / data aggregation challenges =20 Individual clients in general will generate their unique mitigation = requests =96 but may have common information (e.g. same protocol, ports, = alias-name). If the mitigation requests are not unique then we have potential = conflicts =96 not part of this discussion. =20 Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes =96 aggregating different port requirements = for different target-prefixes gets more interesting=85.. This adds in a lot = of potential complexity with potential for boundary condition error issues. =20 Aggregation of Filters is at first sight relatively simple - but there = then may be ordering challenges / conflicts =96 e.g. one filter has an IP = that is a white-list, and another has the same IP as a black-list =96 both valid = in the respective client environment. Ordering of conflicting filter = information is important and I am not sure that a DOTS gateway will do this = properly unless it either has some hints or complex rules to work with =96 just = adding in complexity where more things can potentially go wrong. =20 Use of gateway-identifier and client-identifier combination can be used = to partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 =96 24 *-identifiers in total due to packet MTU. Even if = we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 =96 20. Do we = really want to restrict the number of supported DOTS clients per DOTS gateway = if aggregation is supported? =20 [Med] I guess you meant =93restrict the number of aggregated clients per = DOTS gateway=94, not the =93number of DOTS clients serviced by a DOTS = gateway=94. I would say this is deployment-specific. A deployment that enables = signal/data channel aggregation is aware of this limitation.=20 =20 [Jon] Yes, that is better phrasing. I still struggle with how do you actually do the aggregation (merging of data/signal) at any gateway = other than in a couple of simple cases out of the many different scenarios. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi all,=20 =20 To avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called =93client-identifier=94. The design allows this = parameter to carry multiple values.=20 =20 Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of multiple = values.=20 =20 The potential deployment cases for multiple values are (without making = any assumption whether these cases are good/bad deployment choices): =20 (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also = cases where multiple DOTS gateways are involved.=20 (2)Requests from multiple clients may be aggregated by the same = server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. =20 =20 The current approach has the merit to not make any assumption on the = gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:=20 =20 Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers = of clients, not gateways.=20 - On-path gateways may include a new parameter called =91gateway-identifier=92 to ease contexts retrieval and avoid potential collisions. =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 =20 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if = multiple gateways are on-path. The order of the values is important because the = first one will be the one pointing to the source DOTS clients.=20 =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 = (in addition to C) =20 We are seeking for feedback from the WG on which direction to take.=20 =20 Thoughts? =20 Cheers, Med =20 =20 =20 ------=_NextPart_000_022A_01D377EC.89780DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med / Kaname,

 

“I propose making = it "MUST NOT":
The = client-identifier attribute MUST NOT = be
      generated and included by the DOTS = client.”

We do need to handle the case of a broken client = (how does the DOTS server know it is a DOTS gateway client or a real = DOTS client?) who does not obey the MUST.

 

“The client-identifier attribute SHOULD NOT be = generated and included by the DOTS client. If a client-identifier was = generated by the DOTS client, the DOTS gateway MUST update the value = with zero probability of the same value among different DOTS = clients.”

 

Is the safer option for = me.

 

Otherwise, see [Jon] = inline (8 times).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 18 December 2017 = 06:59
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Jon,

 

Thank you for sharing your thoughts. =

 

Please see comments = inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : samedi 16 d=E9cembre 2017 = 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”

[Med] There are also some complications even = when no aggregation is in use. See below.

 

.  I am leaning = towards your Option 2.  Some of my reasoning is = below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

       &nb= sp;           &nbs= p;            = ;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS client (C1ax) ----- (S1x) DOTS gateway = X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)    =

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  |         &= nbsp;           &n= bsp;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway = Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOTS forwarding = path will always be the same (that is, the same set of gateways will be = solicited for requests coming from a given DOTS = client).

 

[Jon] The current text = states “If the 'client-identifier' value is already present in = the

=A0=A0 = mitigation request received from the DOTS client, the DOTS = gateway

=A0=A0 MAY = compute the 'client-identifier' value, as discussed above, = and

=A0=A0 add = the computed 'client-identifier' value to the end of the = 'client-

=A0=A0 identifier' = list.”

 

[Jon]=A0 The MAY is not = a MUST for the simple reason that if the original DOTS client = client-identifier is computed correctly, it should be unique all the way = through the different DOTS gateways (so no additional client-identifiers = need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C= 1ax)]. =A0The DOTS gateways in the path can then change over time with = no issues.

 

[Jon] All that is = required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional = client-identifiers (but still adds in the first one if the first DOTS = gateway).

 

[Jon] NOTE: A DOTS = gateway can elect to not add in any client-identifier – even if it = is the first in the chain if it wants to hide the client information, = but this will potentially cause information differentiation issues at = the DOTS server and I would not recommend it as client-identifiers, if = created properly, obfuscate the actual client information.

 

[Med]I do see some implications of this design in a = multi-homing scenario with the same mitigation provider: the same = request from a multi-homed DOTS client will be presented to the server = as being distinct requests…while this is not. It may be the same = request that is forked among existent network attachments or a request = that is sent over a first link, but a subsequent one over another = link.

 

[Jon] Perhaps I am = missing something here, but I would be expecting a multi-homed device to = be using the same PKI certificate (or equivalent) in which case the = client-identifier (which is not IP based) would be the same over the = different network interfaces.=A0

 

[Jon] If however, the = different network interfaces are connected to different DOTS provider = domains, then there will be multiple PKI certs, and hence different = client-identifiers propagating up to the DOTS servers – but as = these are different provider domains will they ever join up into a = common domain?=A0 If they do, then this is where you could be getting = conflicting requests – subject of another = discussion.

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation). =    

 

[Jon] Yes – the = assumption being that all the client-identifiers are unique – In = which case I argue again that additional information – e.g. = gateway-identifiers are irrelevant (and also are useless when there are = multiple paths through the DOTS gateways as you refer to = above).

 

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 = can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

[Med] Agree.

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

[Med] I guess you meant “restrict the = number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would = say this is deployment-specific. A deployment that enables signal/data = channel aggregation is aware of this limitation. =

 

[Jon] Yes, that is = better phrasing.=A0 I still struggle with how do you actually do the = aggregation (merging of data/signal) at any gateway other than in a = couple of simple cases out of the many different = scenarios.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the = server select the appropriate policy to enforce, signal/data channel = protocol drafts specify a parameter called = “client-identifier”. The design allows this parameter to = carry multiple values.

 

Putting aside the extensibility argument of the data = model, the signal/data channel protocol drafts are silent about the = exact use of multiple values.

 

The potential deployment cases for multiple values are = (without making any assumption whether these cases are good/bad = deployment choices):

 

(1)Multiple = gateways may be on path. For example, draft-ietf-dots-architecture = discusses recursive signaling and also cases where multiple DOTS = gateways are involved.

(2)Requests = from multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The current approach has the merit to not make any = assumption on the gateway behavior (e.g., (2)), but it leads to a = confusion. For example, a DOTS server does not know whether multiple = client-ids supplied in a messages refer to multiple DOTS clients or to a = DOTS client and a set of on-path gateways. The protocol documents need = to be updated to avoid such confusion. Two options are listed below: =

 

Option 1 (Avoid making any assumption on gateways/proper = semantic distinction between clients and on-path = gateways)

-    Restrict the usage of ‘client-identifier’ to = carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘gateway-identifier’ pointing to = G1

 

Option 2 (Describe what a gateway cannot = do)

-    Update the architecture document to indicate that requests = are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values = only and only if multiple gateways are on-path. The order of the values = is important because the first one will be the one pointing to the = source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘client-identifier’ pointing to G1 = (in addition to C)

 

We are seeking for feedback from the WG on which direction = to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_022A_01D377EC.89780DD0-- From nobody Mon Dec 18 04:27:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95343127023 for ; Mon, 18 Dec 2017 04:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_aRXlqXfgAi for ; Mon, 18 Dec 2017 04:27:48 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10E4129515 for ; Mon, 18 Dec 2017 04:27:47 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 39374120BD4; Mon, 18 Dec 2017 13:27:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 14FCAC0060; Mon, 18 Dec 2017 13:27:46 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 13:27:46 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7Vmg0d1E4KDzX4gQ Date: Mon, 18 Dec 2017 12:27:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> In-Reply-To: <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09A149OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 12:27:53 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09A149OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09A149OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see in= line.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuk= a
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …= but broken clients may communicate directly with servers without any gatewa= y on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actuall= y,

=B7    &n= bsp;    (R1) = we do need MUST so that as a general rule clients do not insert a client-id= parameter in their requests.

=B7    &n= bsp;    And (= R2) DOTS servers MUST ignore client-ids that are supplied by the origin DOT= S clients.

 

In deployment= s without gateways, client-ids supplied by broken DOTS clients will be igno= red by the server as per R2.

In deployment= s with gateways, the first server-side gateway will follow R2 and strip any= value supplied by the client.

 

If we add tex= t to cover (R2), I don’t think we need a sentence about updating the = content because client-id is a value that is ***assigned*** exclusively by a dots gateway:

 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;           &nbs= p;            &= nbsp;          ^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^  

&= nbsp;     in a manner that ensures that there is z= ero probability that the

&= nbsp;     same value will be assigned to a different DO= TS client. 

 =

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for= sharing your thoughts.

 

Please see co= mments inline.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There a= re also some complications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client = (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ---= -------\  

DOTS client = (C1bj) ----------------------------------------/    &nb= sp;            =              &n= bsp;   |

  =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

DOTS client = (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) ---= ----- (S3)   

DOTS client = (C1bx) --------/          = ;            &n= bsp;        |   &nbs= p;            &= nbsp;            &nb= sp; 

  =             &nb= sp;            =             &nb= sp;            =        |     &n= bsp;            = ;             &= nbsp; 

DOTS client = (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/    &nb= sp;            =              &n= bsp;  

DOTS client = (C1by) --------/          = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This as= sumes that the DOTS forwarding path will always be the same (that is, the s= ame set of gateways will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree f= or the first server-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this = design in a multi-homing scenario with the same mitigation provider: the same req= uest from a multi-homed DOTS client will be presented to the server as bein= g distinct requests…while this is not. It may be the same request tha= t is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over ano= ther link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’= ;m referring to this “[alias-name=3DServer1&client-identifer=3DCI= (C1ax),CI(C2x),CI(C3k)]”.=

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, t= hese are deployment-specific. My concern is to avoid design choices that ma= ke hidden assumptions.  

 

 

[Med] Separating both client-id fro= m gateway-id does not suffer from this issue (even when no aggregation). &n= bsp;  

 =

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we a= gree that one (unique) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess= you meant “restrict the number of aggregated clients per DOTS gatewa= y”, not the “number of DOTS clients serviced by a DOTS gateway&= #8221;. I would say this is deployment-specific. A deployment that enables signal/= data channel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please = note that I used “good/bad deployme= nt choices” in the initial message. Merging the requests will induce some complexity a= t the gateway, sure. From a protocol standpoint, I’m trying to be neu= tral on this. My main concern is to avoid making choices in the protocol th= at will have deployment implications.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

- = ;   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

- = ;   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A09A149OPEXCLILMA3corp_-- From nobody Mon Dec 18 05:04:30 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BE512895E for ; Mon, 18 Dec 2017 05:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKQ61qTk_GVP for ; Mon, 18 Dec 2017 05:04:18 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E75129516 for ; Mon, 18 Dec 2017 05:04:17 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 70348120C91; Mon, 18 Dec 2017 14:04:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 402D018006B; Mon, 18 Dec 2017 14:04:16 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 14:04:16 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7Vmg0d1E4KDzX4gQweavL4A= Date: Mon, 18 Dec 2017 13:04:15 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09A18FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:04:28 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09A18FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09A18FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jon,

 

Please see be= low two proposed changes to hopefully conclude on the issues discussed in t= his thread:

 

1st change:

 

OLD:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by the DOTS

&= nbsp;     gateway to propagate the DOTS client identity= from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server.  This al= lows the DOTS server to

&= nbsp;     accept mitigation requests with scopes which = the DOTS client is

&= nbsp;    authorized to manage.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;     in a manner that ensures that there is zero p= robability that the

&= nbsp;     same value will be assigned to a different DO= TS client.  The DOTS

&= nbsp;     gateway MUST conceal potentially sensitive DO= TS client identity

&= nbsp;     information.  The client-identifier attr= ibute SHOULD NOT be

&= nbsp;     generated and included by the DOTS client.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

NEW:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by a

&= nbsp;     server-side DOTS gateway to propagate the DOT= S client identity

&= nbsp;     from the gateway's client-side to the gateway= 's server-side, and

&= nbsp;     from the gateway's server-side to the DOTS se= rver. 'client-

&= nbsp;     identifier' MAY be used by the final DOTS ser= ver for policy

&= nbsp;     enforcement purposes.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the server-side

&= nbsp;     DOTS gateway in a manner that ensures that th= ere is zero

&= nbsp;     probability that the same value will be assig= ned to a different

&= nbsp;     DOTS client.  The server-side DOTS gatew= ay MUST conceal

&= nbsp;     potentially sensitive DOTS client identity in= formation.

<= o:p> 

&= nbsp;     If aggregating DOTS mitigation requests recei= ved from multiple

&= nbsp;     DOTS clients is enabled, the server-side DOTS= gateway has to include

&= nbsp;     a list of 'client-identifier' values; each va= lue is pointing to a

&= nbsp;     DOTS client.  It is out of scope of this= document to specify how

&= nbsp;     aggregation is implemented by a DOTS gateway.=

<= o:p> 

&= nbsp;     The client-identifier attribute MUST NOT be g= enerated and included

&= nbsp;     by DOTS clients.

<= o:p> 

&= nbsp;     DOTS servers MUST ignore client-identifier at= tributes that are

&= nbsp;     directly supplied by source DOTS clients.&nbs= p; This implies that first

&= nbsp;     server-side DOTS gateways MUST strip client-i= dentifier attributes

&= nbsp;     supplied by DOTS clients.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

2nd change: Delete this text because client-identifier is uniquely assigned b= y the first server-side gateway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

&= nbsp;  If the 'client-identifier' value is already present in the=

&= nbsp;  mitigation request received from the DOTS client, the DOTS gate= way

&= nbsp;  MAY compute the 'client-identifier' value, as discussed above, = and

&= nbsp;  add the computed 'client-identifier' value to the end of the 'c= lient-

&= nbsp;  identifier' list.

 

Comments and = modifications are more welcome.

 

Cheers,<= /o:p>

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.org; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see in= line.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …= but broken clients may communicate directly with servers without any gatewa= y on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actuall= y,

=B7    &n= bsp;    (R1) = we do need MUST so that as a general rule clients do not insert a client-id= parameter in their requests.

=B7    &n= bsp;    And (= R2) DOTS servers MUST ignore client-ids that are supplied by the origin DOT= S clients.

 

In deployment= s without gateways, client-ids supplied by broken DOTS clients will be igno= red by the server as per R2.

In deployment= s with gateways, the first server-side gateway will follow R2 and strip any= value supplied by the client.

 

If we add tex= t to cover (R2), I don’t think we need a sentence about updating the = content because client-id is a value that is ***assigned*** exclusively by a dots gateway:

 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;           &nbs= p;            &= nbsp;          ^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^  

&= nbsp;     in a manner that ensures that there is z= ero probability that the

&= nbsp;     same value will be assigned to a different DO= TS client. 

 =

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for= sharing your thoughts.

 

Please see co= mments inline.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There a= re also some complications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client = (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ---= -------\  

DOTS client = (C1bj) ----------------------------------------/    &nb= sp;            =              &n= bsp;   |

  =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

DOTS client = (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) ---= ----- (S3)   

DOTS client = (C1bx) --------/          = ;            &n= bsp;        |   &nbs= p;            &= nbsp;            &nb= sp; 

  =             &nb= sp;            =             &nb= sp;            =        |     &n= bsp;            = ;             &= nbsp; 

DOTS client = (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/    &nb= sp;            =              &n= bsp;  

DOTS client = (C1by) --------/          = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This as= sumes that the DOTS forwarding path will always be the same (that is, the s= ame set of gateways will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree f= or the first server-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this = design in a multi-homing scenario with the same mitigation provider: the same req= uest from a multi-homed DOTS client will be presented to the server as bein= g distinct requests…while this is not. It may be the same request tha= t is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over ano= ther link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’= ;m referring to this “[alias-name=3DServer1&client-identifer=3DCI= (C1ax),CI(C2x),CI(C3k)]”.=

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, t= hese are deployment-specific. My concern is to avoid design choices that ma= ke hidden assumptions.  

 

 

[Med] Separating both client-id fro= m gateway-id does not suffer from this issue (even when no aggregation). &n= bsp;  

 =

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we a= gree that one (unique) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess= you meant “restrict the number of aggregated clients per DOTS gatewa= y”, not the “number of DOTS clients serviced by a DOTS gateway&= #8221;. I would say this is deployment-specific. A deployment that enables signal/= data channel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please = note that I used “good/bad deployme= nt choices” in the initial message. Merging the requests will induce some complexity a= t the gateway, sure. From a protocol standpoint, I’m trying to be neu= tral on this. My main concern is to avoid making choices in the protocol th= at will have deployment implications.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

- = ;   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

- = ;   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A09A18FOPEXCLILMA3corp_-- From nobody Mon Dec 18 05:54:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1868B129C6E for ; Mon, 18 Dec 2017 05:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1lKs997FKCW for ; Mon, 18 Dec 2017 05:53:59 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729B9124217 for ; Mon, 18 Dec 2017 05:53:58 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQvre-0004Id-Fy; Mon, 18 Dec 2017 13:53:54 +0000 From: "Jon Shallow" To: , , "kaname nishizuka" References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 18 Dec 2017 13:53:55 -0000 Message-ID: <028f01d37807$a547b2c0$efd71840$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0290_01D37807.A54C6DB0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nANCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFqgos49sA== Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:54:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0290_01D37807.A54C6DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Going in the right direction, but see comments inline [Jon1]. =20 As a side comment, I always have to think twice what =93DOTS gateway server-side=94 actually means. It actually means the DOTS client = component logic of a DOTS gateway. There is no definition of terms in the signal channel draft, but the definition could perhaps be added to the dots requirements draft. Others may also get confused about this. Perhaps = =93DOTS gateway server-facing-side=94 is clearer, even though much longer to = type! =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Jon,=20 =20 Please see below two proposed changes to hopefully conclude on the = issues discussed in this thread: =20 1st change:=20 =20 OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. =20 The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. =20 This is an optional attribute. =20 NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. =20 The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway = are separate (the server-facing component has no real knowledge of what is happening on the client-facing side), it needs to be the = client-facing-side of the DOTS gateway that assigns the (unique) client-identifier which is then passed over to the server-facing-side for onward transmission. DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. =20 If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to = include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer =93a list of 'client-identifier' values; each value is pointing to a unique DOTS client that is in the aggregated list. It is out of=85.=94 aggregation is implemented by a DOTS gateway. =20 The client-identifier attribute MUST NOT be generated and included by DOTS clients. =20 DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the = client component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server? There is nothing that I have spotted for this in the DOTS = signal protocol. =20 [Jon1] I do agree that true DOTS clients MUST NOT generate =91client-identifiers=92. If only the DOTS gateway server component (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is only = the DOTS server component who is allowed to do the generation. =20 [Jon1] In my implementation the DOTS server (gateway or not) always generates a client-identifier (will be changed if there already is a = unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differentiate between the same mitigation-id from different clients. =20 This is an optional attribute. =20 2nd change: Delete this text because client-identifier is uniquely = assigned by the first server-side gateway; there is no need to prepend = identifiers computed by other gateways.=20 =20 OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK=20 =20 Comments and modifications are more welcome.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med / Kaname, =20 =93I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client.=94 We do need to handle the case of a broken client (how does the DOTS = server know it is a DOTS gateway client or a real DOTS client?) who does not = obey the MUST. [Med] =85but broken clients may communicate directly with servers = without any gateway on the path.=20 =20 =93The client-identifier attribute SHOULD NOT be generated and included = by the DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.=94 =20 Is the safer option for me. =20 [Med] Actually,=20 =B7 (R1) we do need MUST so that as a general rule clients do = not insert a client-id parameter in their requests.=20 =B7 And (R2) DOTS servers MUST ignore client-ids that are = supplied by the origin DOTS clients.=20 =20 In deployments without gateways, client-ids supplied by broken DOTS = clients will be ignored by the server as per R2.=20 In deployments with gateways, the first server-side gateway will follow = R2 and strip any value supplied by the client.=20 =20 If we add text to cover (R2), I don=92t think we need a sentence about updating the content because client-id is a value that is ***assigned*** exclusively by a dots gateway: =20 The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = =20 in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. =20 =20 Otherwise, see [Jon] inline (8 times). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Thank you for sharing your thoughts.=20 =20 Please see comments inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med and all, =20 I think that =91gateway-identifier=92 is likely to cause more confusion = and will not actually help to try and solve what I perceive is the underlying = issue that has triggered this discussion - =93How do we handle = =91client-identifiers=92 when a DOTS gateway does aggregation?=94 [Med] There are also some complications even when no aggregation is in = use. See below.=20 =20 . I am leaning towards your Option 2. Some of my reasoning is below. =20 Background to client-identifiers. =20 In the general case (e.g. no DOTS gateway aggregation of filters / = aliases etc.), every time a request or update (both signal and data) passes = upstream through a DOTS gateway, an additional =91client-identifier=92 is added = to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, = say, an (possibly non unique alias-name) alias definition sent over the data = channel with a (possibly non unique mitigation-id) mitigation request using the = same alias-name sent over the signal channel. =20 Client Identification Usage Example =20 DOTS client (C1aj) ------------------------------------- (S1j) DOTS = gateway J (C2j) ----------\ =20 DOTS client (C1bj) ----------------------------------------/ | =20 | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS = gateway K (C3k) -------- (S3) =20 DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ =20 Where CI is =91client-identifier=92 =96 a unique hash of the client = identification :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)] =20 [Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client). =20 [Jon] The current text states =93If the 'client-identifier' value is = already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list.=94 =20 [Jon] The MAY is not a MUST for the simple reason that if the original = DOTS client client-identifier is computed correctly, it should be unique all = the way through the different DOTS gateways (so no additional = client-identifiers need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C1ax)]. The DOTS gateways = in the path can then change over time with no issues. =20 [Jon] All that is required then is that a DOTS gateway makes sure that = any Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional client-identifiers = (but still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway.=20 =20 [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier = =96 even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information. =20 [Med]I do see some implications of this design in a multi-homing = scenario with the same mitigation provider: the same request from a multi-homed = DOTS client will be presented to the server as being distinct = requests=85while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a = subsequent one over another link. =20 [Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) = in which case the client-identifier (which is not IP based) would be the = same over the different network interfaces. =20 [Med] I=92m referring to this =93[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]=94.= =20 [Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, = and hence different client-identifiers propagating up to the DOTS servers = =96 but as these are different provider domains will they ever join up into a = common domain? If they do, then this is where you could be getting conflicting requests =96 subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design choices that make hidden assumptions. =20 =20 =20 [Med] Separating both client-id from gateway-id does not suffer from = this issue (even when no aggregation). =20 =20 [Jon] Yes =96 the assumption being that all the client-identifiers are = unique =96 In which case I argue again that additional information =96 e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I=92m = fine.=20 =20 so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different CI(). =20 Then when C1ax requests a mitigation with alias-name=3DServer1, by the = time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]. =20 If C1aj also requests a mitigation with alias-name=3DServer1, S3 will = see the alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] = and match accordingly. =20 As responses come back from S3 to the originating client, the = appropriate CI(cxxx) gets stripped off so the originating client sees no =91client-identifier=92 fields at all. =20 This general solution is simple with only one disadvantage =96 there is = a limit of 20 - 24 client-identifiers (20 =96 24 DOTS gateways) that will = fit into a single UDP packet due to MTU restrictions. However in practice = there are unlikely to be this number of DOTS gateways. The count varies based = on how much other information needs to be put into the packet. =20 DOTS Gateway Session aggregation =20 There is no reason as to why multiple DOTS clients=92 signal and data = requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection =96 especially as different client-identifiers = separate out the different requests / responses. =20 This session aggregation is not the same as signal / data aggregation =20 NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation =20 [Med] Agree.=20 =20 DOTS Gateway signal / data aggregation challenges =20 Individual clients in general will generate their unique mitigation = requests =96 but may have common information (e.g. same protocol, ports, = alias-name). If the mitigation requests are not unique then we have potential = conflicts =96 not part of this discussion. =20 Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes =96 aggregating different port requirements = for different target-prefixes gets more interesting=85.. This adds in a lot = of potential complexity with potential for boundary condition error issues. =20 Aggregation of Filters is at first sight relatively simple - but there = then may be ordering challenges / conflicts =96 e.g. one filter has an IP = that is a white-list, and another has the same IP as a black-list =96 both valid = in the respective client environment. Ordering of conflicting filter = information is important and I am not sure that a DOTS gateway will do this = properly unless it either has some hints or complex rules to work with =96 just = adding in complexity where more things can potentially go wrong. =20 Use of gateway-identifier and client-identifier combination can be used = to partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 =96 24 *-identifiers in total due to packet MTU. Even if = we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 =96 20. Do we = really want to restrict the number of supported DOTS clients per DOTS gateway = if aggregation is supported? =20 [Med] I guess you meant =93restrict the number of aggregated clients per = DOTS gateway=94, not the =93number of DOTS clients serviced by a DOTS = gateway=94. I would say this is deployment-specific. A deployment that enables = signal/data channel aggregation is aware of this limitation.=20 =20 [Jon] Yes, that is better phrasing. [Med] OK.=20 =20 I still struggle with how do you actually do the aggregation (merging = of data/signal) at any gateway other than in a couple of simple cases out = of the many different scenarios. [Med] Please note that I used =93good/bad deployment choices=94 in the = initial message. Merging the requests will induce some complexity at the = gateway, sure. From a protocol standpoint, I=92m trying to be neutral on this. My = main concern is to avoid making choices in the protocol that will have = deployment implications. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi all,=20 =20 To avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called =93client-identifier=94. The design allows this = parameter to carry multiple values.=20 =20 Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of multiple = values.=20 =20 The potential deployment cases for multiple values are (without making = any assumption whether these cases are good/bad deployment choices): =20 (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also = cases where multiple DOTS gateways are involved.=20 (2)Requests from multiple clients may be aggregated by the same = server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. =20 =20 The current approach has the merit to not make any assumption on the = gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:=20 =20 Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers = of clients, not gateways.=20 - On-path gateways may include a new parameter called =91gateway-identifier=92 to ease contexts retrieval and avoid potential collisions. =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 =20 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if = multiple gateways are on-path. The order of the values is important because the = first one will be the one pointing to the source DOTS clients.=20 =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 = (in addition to C) =20 We are seeking for feedback from the WG on which direction to take.=20 =20 Thoughts? =20 Cheers, Med =20 =20 =20 ------=_NextPart_000_0290_01D37807.A54C6DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Going in the right = direction, but see comments inline [Jon1].

 

As a side comment, I = always have to think twice what “DOTS gateway server-side” = actually means.=A0 It actually means the DOTS client component = logic of a DOTS gateway.=A0 There is no definition of terms in the = signal channel draft, but the definition could perhaps be added to the = dots requirements draft.=A0 Others may also get confused about this.=A0 = Perhaps “DOTS gateway server-facing-side” is clearer, even = though much longer to type!

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 18 December 2017 = 13:04
To: Jon Shallow; dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Jon,

 

Please see below two proposed changes to = hopefully conclude on the issues discussed in this = thread:

 

1st change: =

 

OLD:

   = client-identifier:  The client identifier MAY be conveyed by the = DOTS

      = gateway to propagate the DOTS client identity from the = gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server.  This allows the DOTS server = to

      = accept mitigation requests with scopes which the DOTS client = is

     autho= rized to manage.

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      in = a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  The = DOTS

      = gateway MUST conceal potentially sensitive DOTS client = identity

      = information.  The client-identifier attribute SHOULD NOT = be

      = generated and included by the DOTS client.

 

      = This is an optional attribute.

 

NEW:

   = client-identifier:  The client identifier MAY be conveyed by = a

      = server-side DOTS gateway to propagate the DOTS client = identity

      = from the gateway's client-side to the gateway's server-side, = and

      = from the gateway's server-side to the DOTS server. = 'client-

      = identifier' MAY be used by the final DOTS server for = policy

      = enforcement purposes.

 

      The = 'client-identifier' value MUST be assigned by the = server-side

[Jon1]=A0 Actually, as = the client and server components of a DOTs gateway are separate (the = server-facing component has no real knowledge of what is happening on = the client-facing side), it needs to be the client-facing-side of the = DOTS gateway that assigns the (unique) client-identifier which is then = passed over to the server-facing-side for onward = transmission.

      = DOTS gateway in a manner that ensures that there is = zero

      = probability that the same value will be assigned to a = different

      = DOTS client.  The server-side DOTS gateway MUST = conceal

      = potentially sensitive DOTS client identity = information.

 

      If = aggregating DOTS mitigation requests received from = multiple

      = DOTS clients is enabled, the server-side DOTS gateway has to = include

      a = list of 'client-identifier' values; each value is pointing to = a

      = DOTS client.  It is out of scope of this document to specify = how

[Jon1] I prefer “a = list of 'client-identifier' values; each value is pointing to a = unique

=A0=A0=A0=A0=A0 DOTS = client that is in the aggregated list.=A0 It is out = of….”

      = aggregation is implemented by a DOTS gateway.

 

      The = client-identifier attribute MUST NOT be generated and = included

      by = DOTS clients.

 

      = DOTS servers MUST ignore client-identifier attributes that = are

      = directly supplied by source DOTS clients.  This implies that = first

      = server-side DOTS gateways MUST strip client-identifier = attributes

      = supplied by DOTS clients.

[Jon1] How do we = differentiate between an actual DOTS client and the client component of = a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server?=A0 = There is nothing that I have spotted for this in the DOTS signal = protocol.

 <= /p>

[Jon1] I do agree that = true DOTS clients MUST NOT generate ‘client-identifiers’. If = only the DOTS gateway server component (client-facing-side) is allowed = to generate the client-identifier (for possible onward forwarding), this = gets around this issue as it is only the DOTS server component who is = allowed to do the generation.

 <= /p>

[Jon1] In my = implementation the DOTS server (gateway or not) always generates a = client-identifier (will be changed if there already is a unique = identifier following this discussion) which is associated with a = mitigation-id etc. so that the DOTS server can differentiate between the = same mitigation-id from different clients.

 

      = This is an optional attribute.

 

2nd change: Delete this text = because client-identifier is uniquely assigned by the first server-side = gateway; there is no need to prepend identifiers computed by other = gateways.

 

OLD:

   If the = 'client-identifier' value is already present in = the

   mitigation request = received from the DOTS client, the DOTS gateway

   MAY compute the = 'client-identifier' value, as discussed above, = and

   add the computed = 'client-identifier' value to the end of the = 'client-

   identifier' = list.

[Jon1] OK =

 

Comments and modifications are more welcome. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de mohamed.boucadair@orange.com=
Envoy=E9 : lundi 18 d=E9cembre 2017 = 13:28
=C0 : Jon Shallow; dots@ietf.org; kaname = nishizuka
Objet : Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi Med / = Kaname,

 

“I = propose making it "MUST NOT":
The client-identifier attribute MUST NOT = be
      generated and included by the DOTS = client.”

We do need to handle the case of a broken client = (how does the DOTS server know it is a DOTS gateway client or a real = DOTS client?) who does not obey the MUST.

[Med] …but broken clients may = communicate directly with servers without any gateway on the path. =

 

“The = client-identifier attribute SHOULD NOT be generated and included by the = DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.”

 

Is the safer option for = me.

 

[Med] Actually,

=B7         = (R1) we do need MUST so that as a general rule = clients do not insert a client-id parameter in their requests. =

=B7         = And (R2) DOTS servers MUST ignore client-ids = that are supplied by the origin DOTS clients.

 

In deployments without gateways, client-ids = supplied by broken DOTS clients will be ignored by the server as per R2. =

In deployments with gateways, the first = server-side gateway will follow R2 and strip any value supplied by the = client.

 

If we add text to cover (R2), I don’t = think we need a sentence about updating the content because client-id is = a value that is ***assigned*** exclusively by a dots = gateway:

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      = ;            =             &= nbsp;     = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   =

      = ;in a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  =

 

Otherwise, see [Jon] inline (8 = times).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 06:59
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Jon,

 

Thank you for sharing your thoughts. =

 

Please see comments = inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : samedi 16 d=E9cembre 2017 = 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”

[Med] There are also some complications even = when no aggregation is in use. See below.

 

.  I am leaning = towards your Option 2.  Some of my reasoning is = below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

       &nb= sp;           &nbs= p;            = ;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS client (C1ax) ----- (S1x) DOTS gateway = X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)    =

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  |         &= nbsp;           &n= bsp;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway = Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOTS forwarding = path will always be the same (that is, the same set of gateways will be = solicited for requests coming from a given DOTS = client).

 

[Jon] The current text = states “If the 'client-identifier' value is already present in = the

   = mitigation request received from the DOTS client, the DOTS = gateway

   = MAY compute the 'client-identifier' value, as discussed above, = and

   = add the computed 'client-identifier' value to the end of the = 'client-

   identifier' = list.”

 

[Jon]  The MAY is = not a MUST for the simple reason that if the original DOTS client = client-identifier is computed correctly, it should be unique all the way = through the different DOTS gateways (so no additional client-identifiers = need to get added) so that S3 just sees = [alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS = gateways in the path can then change over time with no = issues.

 

[Jon] All that is = required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional = client-identifiers (but still adds in the first one if the first DOTS = gateway).

[Med] Agree for the first server-side gateway. =

 

[Jon] NOTE: A DOTS = gateway can elect to not add in any client-identifier – even if it = is the first in the chain if it wants to hide the client information, = but this will potentially cause information differentiation issues at = the DOTS server and I would not recommend it as client-identifiers, if = created properly, obfuscate the actual client information.

 

[Med]I do see some implications of this design in a = multi-homing scenario with the same mitigation provider: the same = request from a multi-homed DOTS client will be presented to the server = as being distinct requests…while this is not. It may be the same = request that is forked among existent network attachments or a request = that is sent over a first link, but a subsequent one over another = link.

 

[Jon] Perhaps I am = missing something here, but I would be expecting a multi-homed device to = be using the same PKI certificate (or equivalent) in which case the = client-identifier (which is not IP based) would be the same over the = different network interfaces. 

[Med] I’m referring to this = “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

 

[Jon] If however, the = different network interfaces are connected to different DOTS provider = domains, then there will be multiple PKI certs, and hence different = client-identifiers propagating up to the DOTS servers – but as = these are different provider domains will they ever join up into a = common domain?  If they do, then this is where you could be getting = conflicting requests – subject of another = discussion.

[Med] Sure, these are deployment-specific. My = concern is to avoid design choices that make hidden assumptions. =  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation). =    

 

[Jon] Yes – the = assumption being that all the client-identifiers are unique – In = which case I argue again that additional information – e.g. = gateway-identifiers are irrelevant (and also are useless when there are = multiple paths through the DOTS gateways as you refer to = above).

[Med] If we agree that one (unique) client-id = is supplied, then I’m fine.

 

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 = can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

[Med] Agree.

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

[Med] I guess you meant “restrict the = number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would = say this is deployment-specific. A deployment that enables signal/data = channel aggregation is aware of this limitation. =

 

[Jon] Yes, that is = better phrasing.

[Med] OK.

 

  I still struggle = with how do you actually do the aggregation (merging of data/signal) at = any gateway other than in a couple of simple cases out of the many = different scenarios.

[Med] Please note that I used = “good/bad = deployment choices” in the initial message. Merging the = requests will induce some complexity at the gateway, sure. From a = protocol standpoint, I’m trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have = deployment implications.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the = server select the appropriate policy to enforce, signal/data channel = protocol drafts specify a parameter called = “client-identifier”. The design allows this parameter to = carry multiple values.

 

Putting aside the extensibility argument of the data = model, the signal/data channel protocol drafts are silent about the = exact use of multiple values.

 

The potential deployment cases for multiple values are = (without making any assumption whether these cases are good/bad = deployment choices):

 

(1)Multiple = gateways may be on path. For example, draft-ietf-dots-architecture = discusses recursive signaling and also cases where multiple DOTS = gateways are involved.

(2)Requests = from multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The current approach has the merit to not make any = assumption on the gateway behavior (e.g., (2)), but it leads to a = confusion. For example, a DOTS server does not know whether multiple = client-ids supplied in a messages refer to multiple DOTS clients or to a = DOTS client and a set of on-path gateways. The protocol documents need = to be updated to avoid such confusion. Two options are listed below: =

 

Option 1 (Avoid making any assumption on gateways/proper = semantic distinction between clients and on-path = gateways)

-    Restrict the usage of ‘client-identifier’ to = carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘gateway-identifier’ pointing to = G1

 

Option 2 (Describe what a gateway cannot = do)

-    Update the architecture document to indicate that requests = are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values = only and only if multiple gateways are on-path. The order of the values = is important because the first one will be the one pointing to the = source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘client-identifier’ pointing to G1 = (in addition to C)

 

We are seeking for feedback from the WG on which direction = to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_0290_01D37807.A54C6DB0-- From nobody Mon Dec 18 06:27:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10BF12D0C3 for ; Mon, 18 Dec 2017 06:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsgTKMgOcZJ9 for ; Mon, 18 Dec 2017 06:27:11 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A5A124B17 for ; Mon, 18 Dec 2017 06:27:10 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id BDFC820B52; Mon, 18 Dec 2017 15:27:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 8C6FA12006E; Mon, 18 Dec 2017 15:27:08 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 15:27:08 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFqgos49sKDzcJEw Date: Mon, 18 Dec 2017 14:27:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> In-Reply-To: <028f01d37807$a547b2c0$efd71840$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09A203OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:27:15 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09A203OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, Going in the right direction, but see comments inline [Jon1]. As a side comment, I always have to think twice what "DOTS gateway server-s= ide" actually means. It actually means the DOTS client component logic of = a DOTS gateway. There is no definition of terms in the signal channel draf= t, but the definition could perhaps be added to the dots requirements draft= . Others may also get confused about this. Perhaps "DOTS gateway server-f= acing-side" is clearer, even though much longer to type! [Med] We do have the following definition in the requirements I-D: Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway are= separate (the server-facing component has no real knowledge of what is hap= pening on the client-facing side), it needs to be the client-facing-side of= the DOTS gateway that assigns the (unique) client-identifier which is then= passed over to the server-facing-side for onward transmission. [Med] You are right if we zoom on the internal implementation of a DOTS gat= eway. This part of the text focuses on the external behavior of the DOTS ga= teway. The text does not need to zoom in given that the second sentence abo= ve says; "to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. " DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer "a list of 'client-identifier' values; each value is pointi= ng to a unique DOTS client that is in the aggregated list. It is out of...." [Med] Deal. aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the client= component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS se= rver? There is nothing that I have spotted for this in the DOTS signal pro= tocol. [Med] I confirm, there is no such text in the draft. A deployment would con= sist in explicitly configuring a list of gateways (ACLs) on the server; the= server will trust client-id if and only if it is coming from a server-side= gateways in that list. [Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifi= ers'. If only the DOTS gateway server component (client-facing-side) is all= owed to generate the client-identifier (for possible onward forwarding), th= is gets around this issue as it is only the DOTS server component who is al= lowed to do the generation. [Jon1] In my implementation the DOTS server (gateway or not) always generat= es a client-identifier (will be changed if there already is a unique identi= fier following this discussion) which is associated with a mitigation-id et= c. so that the DOTS server can differentiate between the same mitigation-id= from different clients. [Med] Ok, thanks. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09A203OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuk= a
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

Going i= n the right direction, but see comments inline [Jon1].

&n= bsp;

As a si= de comment, I always have to think twice what “DOTS gateway server-si= de” actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definiti= on of terms in the signal channel draft, but the definition could perhaps b= e added to the dots requirements draft.  Others may also get confused = about this.  Perhaps “DOTS gateway server-facing-side” is clearer, even though much longer to type!

 

[Med] We do h= ave the following definition in the requirements I-D:

 

&= nbsp;     Client-side DOTS gateways

&= nbsp;     are DOTS gateways that are in the DOTS client= 's domain, while

&= nbsp;     server-side DOTS gateways denote DOTS gateway= s that are in the

&= nbsp;     DOTS server's domain.=

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 13:04
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Jon,

 

Please see be= low two proposed changes to hopefully conclude on the issues discussed in t= his thread:

 

1st change:

 

OLD:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by the DOTS

&= nbsp;     gateway to propagate the DOTS client identity= from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server.  This al= lows the DOTS server to

&= nbsp;     accept mitigation requests with scopes which = the DOTS client is

&= nbsp;    authorized to manage.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;     in a manner that ensures that there is zero p= robability that the

&= nbsp;     same value will be assigned to a different DO= TS client.  The DOTS

&= nbsp;     gateway MUST conceal potentially sensitive DO= TS client identity

&= nbsp;     information.  The client-identifier attr= ibute SHOULD NOT be

&= nbsp;     generated and included by the DOTS client.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

NEW:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by a

&= nbsp;     server-side DOTS gateway to propagate the DOT= S client identity

&= nbsp;     from the gateway's client-side to the gateway= 's server-side, and

&= nbsp;     from the gateway's server-side to the DOTS se= rver. 'client-

&= nbsp;     identifier' MAY be used by the final DOTS ser= ver for policy

&= nbsp;     enforcement purposes.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the server-side

[Jon1]  Actually, as the client and server components= of a DOTs gateway are separate (the server-facing component has no real kn= owledge of what is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assi= gns the (unique) client-identifier which is then passed over to the server-= facing-side for onward transmission.

 

[Med] You are right if we zoom on the internal implementation of= a DOTS gateway. This part of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that= the second sentence above says;

 

“to propagate the DOTS client identity from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server. <= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Courier New= ","serif";color:black;mso-fareast-language:FR">”<= /o:p>

 

&= nbsp;     DOTS gateway in a manner that ensures that th= ere is zero

&= nbsp;     probability that the same value will be assig= ned to a different

&= nbsp;     DOTS client.  The server-side DOTS gatew= ay MUST conceal

&= nbsp;     potentially sensitive DOTS client identity in= formation.

<= o:p> 

&= nbsp;     If aggregating DOTS mitigation requests recei= ved from multiple

&= nbsp;     DOTS clients is enabled, the server-side DOTS= gateway has to include

&= nbsp;     a list of 'client-identifier' values; each va= lue is pointing to a

&= nbsp;     DOTS client.  It is out of scope of this= document to specify how

[Jon1] I prefer “a list of 'client-identifier' value= s; each value is pointing to a unique

      DOTS client that is in the = aggregated list.  It is out of….”

 

[Med] Deal.  

 

&= nbsp;     aggregation is implemented by a DOTS gateway.=

<= o:p> 

&= nbsp;     The client-identifier attribute MUST NOT be g= enerated and included

&= nbsp;     by DOTS clients.

<= o:p> 

&= nbsp;     DOTS servers MUST ignore client-identifier at= tributes that are

&= nbsp;     directly supplied by source DOTS clients.&nbs= p; This implies that first

&= nbsp;     server-side DOTS gateways MUST strip client-i= dentifier attributes

&= nbsp;     supplied by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS clie= nt and the client component of a DOTS gateway (i.e. server-facing-side) as = seen by a DOTS server?  There is nothing that I have spotted for this in the DOTS signal protocol.

 

[Med] I confirm, there is no such text in the draft. A deploymen= t would consist in explicitly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is= coming from a server-side gateways in that list.

 

[Jon1] I do agree that true DOTS clients MUST NOT generate= ‘client-identifiers’. If only the DOTS gateway server componen= t (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this = issue as it is only the DOTS server component who is allowed to do the gene= ration.

 

[Jon1] In my implementation the DOTS server (gateway or no= t) always generates a client-identifier (will be changed if there already i= s a unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can = differentiate between the same mitigation-id from different clients.

[Med] Ok, thanks.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

2nd change: Delete this text because client-identifier is uniquely assigned b= y the first server-side gateway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

&= nbsp;  If the 'client-identifier' value is already present in the=

&= nbsp;  mitigation request received from the DOTS client, the DOTS gate= way

&= nbsp;  MAY compute the 'client-identifier' value, as discussed above, = and

&= nbsp;  add the computed 'client-identifier' value to the end of the 'c= lient-

&= nbsp;  identifier' list.

[Jon1] OK

 

Comments and = modifications are more welcome.

 

Cheers,<= /o:p>

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.o= rg; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see in= line.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …= but broken clients may communicate directly with servers without any gatewa= y on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actuall= y,

=B7    &n= bsp;    (R1) = we do need MUST so that as a general rule clients do not insert a client-id= parameter in their requests.

=B7    &n= bsp;    And (= R2) DOTS servers MUST ignore client-ids that are supplied by the origin DOT= S clients.

 

In deployment= s without gateways, client-ids supplied by broken DOTS clients will be igno= red by the server as per R2.

In deployment= s with gateways, the first server-side gateway will follow R2 and strip any= value supplied by the client.

 

If we add tex= t to cover (R2), I don’t think we need a sentence about updating the = content because client-id is a value that is ***assigned*** exclusively by a dots gateway:

 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;           &nbs= p;            &= nbsp;          ^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^  

&= nbsp;     in a manner that ensures that there is z= ero probability that the

&= nbsp;     same value will be assigned to a different DO= TS client. 

 =

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for= sharing your thoughts.

 

Please see co= mments inline.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There a= re also some complications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client = (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ---= -------\  

DOTS client = (C1bj) ----------------------------------------/    &nb= sp;            =              &n= bsp;   |

  =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

DOTS client = (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) ---= ----- (S3)   

DOTS client = (C1bx) --------/          = ;            &n= bsp;        |   &nbs= p;            &= nbsp;            &nb= sp; 

  =             &nb= sp;            =             &nb= sp;            =        |     &n= bsp;            = ;             &= nbsp; 

DOTS client = (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/    &nb= sp;            =              &n= bsp;  

DOTS client = (C1by) --------/          = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This as= sumes that the DOTS forwarding path will always be the same (that is, the s= ame set of gateways will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree f= or the first server-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this = design in a multi-homing scenario with the same mitigation provider: the same req= uest from a multi-homed DOTS client will be presented to the server as bein= g distinct requests…while this is not. It may be the same request tha= t is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over ano= ther link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’= ;m referring to this “[alias-name=3DServer1&client-identifer=3DCI= (C1ax),CI(C2x),CI(C3k)]”.=

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, t= hese are deployment-specific. My concern is to avoid design choices that ma= ke hidden assumptions.  

 

 

[Med] Separating both client-id fro= m gateway-id does not suffer from this issue (even when no aggregation). &n= bsp;  

 =

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we a= gree that one (unique) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess= you meant “restrict the number of aggregated clients per DOTS gatewa= y”, not the “number of DOTS clients serviced by a DOTS gateway&= #8221;. I would say this is deployment-specific. A deployment that enables signal/= data channel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please = note that I used “good/bad deployme= nt choices” in the initial message. Merging the requests will induce some complexity a= t the gateway, sure. From a protocol standpoint, I’m trying to be neu= tral on this. My main concern is to avoid making choices in the protocol th= at will have deployment implications.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

- = ;   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

- = ;   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A09A203OPEXCLILMA3corp_-- From nobody Mon Dec 18 06:50:47 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2BE124D85 for ; Mon, 18 Dec 2017 06:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_e1k_bI56ob for ; Mon, 18 Dec 2017 06:50:42 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2892124B17 for ; Mon, 18 Dec 2017 06:50:41 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQwkX-0004KI-US; Mon, 18 Dec 2017 14:50:38 +0000 From: "Jon Shallow" To: , , "kaname nishizuka" References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 18 Dec 2017 14:50:39 -0000 Message-ID: <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B2_01D3780F.91E5DEC0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nANCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTEToHtDpwA= Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:50:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B2_01D3780F.91E5DEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon2]. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 14:27 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med, =20 Going in the right direction, but see comments inline [Jon1]. =20 As a side comment, I always have to think twice what =93DOTS gateway server-side=94 actually means. It actually means the DOTS client = component logic of a DOTS gateway. There is no definition of terms in the signal channel draft, but the definition could perhaps be added to the dots requirements draft. Others may also get confused about this. Perhaps = =93DOTS gateway server-facing-side=94 is clearer, even though much longer to = type! =20 [Med] We do have the following definition in the requirements I-D:=20 =20 Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. =20 =20 [Jon2] Yes =96 actually, this adds to the confusion in my mind. For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain. The quoted text implies it is one or the other, but not both. =20 [Jon2] Also, being picky, does =93Client-side DOTS gateway=94 (type of = DOTS gateway) actually mean the same as =93DOTS gateway client-side=94 = (component within a DOTS gateway)? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Jon,=20 =20 Please see below two proposed changes to hopefully conclude on the = issues discussed in this thread: =20 1st change:=20 =20 OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. =20 The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. =20 This is an optional attribute. =20 NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. =20 The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway = are separate (the server-facing component has no real knowledge of what is happening on the client-facing side), it needs to be the = client-facing-side of the DOTS gateway that assigns the (unique) client-identifier which is then passed over to the server-facing-side for onward transmission. =20 [Med] You are right if we zoom on the internal implementation of a DOTS gateway. This part of the text focuses on the external behavior of the = DOTS gateway. The text does not need to zoom in given that the second = sentence above says;=20 =20 [Jon2] In terms of helping the implementers, the use of only DOTS server being allowed to generate a =91client-identifier=92 as discussed later. = If =93server-side=94 was removed as in :- =93client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity =85=94 Removes a lot of confusion in my mind. =20 =93to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. =94 =20 DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. =20 If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to = include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer =93a list of 'client-identifier' values; each value is pointing to a unique DOTS client that is in the aggregated list. It is out of=85.=94 =20 [Med] Deal. =20 =20 aggregation is implemented by a DOTS gateway. =20 The client-identifier attribute MUST NOT be generated and included by DOTS clients. =20 DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the = client component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server? There is nothing that I have spotted for this in the DOTS = signal protocol. =20 [Med] I confirm, there is no such text in the draft. A deployment would consist in explicitly configuring a list of gateways (ACLs) on the = server; the server will trust client-id if and only if it is coming from a server-side gateways in that list. =20 [Jon2] Then do we need to instruct the implementers of the signal = channel that this is what should be done? [Jon1] I do agree that true DOTS clients MUST NOT generate =91client-identifiers=92. If only the DOTS gateway server component (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is only = the DOTS server component who is allowed to do the generation. =20 [Jon1] In my implementation the DOTS server (gateway or not) always generates a client-identifier (will be changed if there already is a = unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differentiate between the same mitigation-id from different clients. [Med] Ok, thanks. =20 This is an optional attribute. =20 2nd change: Delete this text because client-identifier is uniquely = assigned by the first server-side gateway; there is no need to prepend = identifiers computed by other gateways.=20 =20 OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK=20 =20 Comments and modifications are more welcome.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med / Kaname, =20 =93I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client.=94 We do need to handle the case of a broken client (how does the DOTS = server know it is a DOTS gateway client or a real DOTS client?) who does not = obey the MUST. [Med] =85but broken clients may communicate directly with servers = without any gateway on the path.=20 =20 =93The client-identifier attribute SHOULD NOT be generated and included = by the DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.=94 =20 Is the safer option for me. =20 [Med] Actually,=20 =B7 (R1) we do need MUST so that as a general rule clients do = not insert a client-id parameter in their requests.=20 =B7 And (R2) DOTS servers MUST ignore client-ids that are = supplied by the origin DOTS clients.=20 =20 In deployments without gateways, client-ids supplied by broken DOTS = clients will be ignored by the server as per R2.=20 In deployments with gateways, the first server-side gateway will follow = R2 and strip any value supplied by the client.=20 =20 If we add text to cover (R2), I don=92t think we need a sentence about updating the content because client-id is a value that is ***assigned*** exclusively by a dots gateway: =20 The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = =20 in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. =20 =20 Otherwise, see [Jon] inline (8 times). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Thank you for sharing your thoughts.=20 =20 Please see comments inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med and all, =20 I think that =91gateway-identifier=92 is likely to cause more confusion = and will not actually help to try and solve what I perceive is the underlying = issue that has triggered this discussion - =93How do we handle = =91client-identifiers=92 when a DOTS gateway does aggregation?=94 [Med] There are also some complications even when no aggregation is in = use. See below.=20 =20 . I am leaning towards your Option 2. Some of my reasoning is below. =20 Background to client-identifiers. =20 In the general case (e.g. no DOTS gateway aggregation of filters / = aliases etc.), every time a request or update (both signal and data) passes = upstream through a DOTS gateway, an additional =91client-identifier=92 is added = to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, = say, an (possibly non unique alias-name) alias definition sent over the data = channel with a (possibly non unique mitigation-id) mitigation request using the = same alias-name sent over the signal channel. =20 Client Identification Usage Example =20 DOTS client (C1aj) ------------------------------------- (S1j) DOTS = gateway J (C2j) ----------\ =20 DOTS client (C1bj) ----------------------------------------/ | =20 | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS = gateway K (C3k) -------- (S3) =20 DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ =20 Where CI is =91client-identifier=92 =96 a unique hash of the client = identification :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)] =20 [Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client). =20 [Jon] The current text states =93If the 'client-identifier' value is = already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list.=94 =20 [Jon] The MAY is not a MUST for the simple reason that if the original = DOTS client client-identifier is computed correctly, it should be unique all = the way through the different DOTS gateways (so no additional = client-identifiers need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C1ax)]. The DOTS gateways = in the path can then change over time with no issues. =20 [Jon] All that is required then is that a DOTS gateway makes sure that = any Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional client-identifiers = (but still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway.=20 =20 [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier = =96 even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information. =20 [Med]I do see some implications of this design in a multi-homing = scenario with the same mitigation provider: the same request from a multi-homed = DOTS client will be presented to the server as being distinct = requests=85while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a = subsequent one over another link. =20 [Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) = in which case the client-identifier (which is not IP based) would be the = same over the different network interfaces. =20 [Med] I=92m referring to this =93[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]=94.= =20 [Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, = and hence different client-identifiers propagating up to the DOTS servers = =96 but as these are different provider domains will they ever join up into a = common domain? If they do, then this is where you could be getting conflicting requests =96 subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design choices that make hidden assumptions. =20 =20 =20 [Med] Separating both client-id from gateway-id does not suffer from = this issue (even when no aggregation). =20 =20 [Jon] Yes =96 the assumption being that all the client-identifiers are = unique =96 In which case I argue again that additional information =96 e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I=92m = fine.=20 =20 so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different CI(). =20 Then when C1ax requests a mitigation with alias-name=3DServer1, by the = time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]. =20 If C1aj also requests a mitigation with alias-name=3DServer1, S3 will = see the alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] = and match accordingly. =20 As responses come back from S3 to the originating client, the = appropriate CI(cxxx) gets stripped off so the originating client sees no =91client-identifier=92 fields at all. =20 This general solution is simple with only one disadvantage =96 there is = a limit of 20 - 24 client-identifiers (20 =96 24 DOTS gateways) that will = fit into a single UDP packet due to MTU restrictions. However in practice = there are unlikely to be this number of DOTS gateways. The count varies based = on how much other information needs to be put into the packet. =20 DOTS Gateway Session aggregation =20 There is no reason as to why multiple DOTS clients=92 signal and data = requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection =96 especially as different client-identifiers = separate out the different requests / responses. =20 This session aggregation is not the same as signal / data aggregation =20 NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation =20 [Med] Agree.=20 =20 DOTS Gateway signal / data aggregation challenges =20 Individual clients in general will generate their unique mitigation = requests =96 but may have common information (e.g. same protocol, ports, = alias-name). If the mitigation requests are not unique then we have potential = conflicts =96 not part of this discussion. =20 Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes =96 aggregating different port requirements = for different target-prefixes gets more interesting=85.. This adds in a lot = of potential complexity with potential for boundary condition error issues. =20 Aggregation of Filters is at first sight relatively simple - but there = then may be ordering challenges / conflicts =96 e.g. one filter has an IP = that is a white-list, and another has the same IP as a black-list =96 both valid = in the respective client environment. Ordering of conflicting filter = information is important and I am not sure that a DOTS gateway will do this = properly unless it either has some hints or complex rules to work with =96 just = adding in complexity where more things can potentially go wrong. =20 Use of gateway-identifier and client-identifier combination can be used = to partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 =96 24 *-identifiers in total due to packet MTU. Even if = we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 =96 20. Do we = really want to restrict the number of supported DOTS clients per DOTS gateway = if aggregation is supported? =20 [Med] I guess you meant =93restrict the number of aggregated clients per = DOTS gateway=94, not the =93number of DOTS clients serviced by a DOTS = gateway=94. I would say this is deployment-specific. A deployment that enables = signal/data channel aggregation is aware of this limitation.=20 =20 [Jon] Yes, that is better phrasing. [Med] OK.=20 =20 I still struggle with how do you actually do the aggregation (merging = of data/signal) at any gateway other than in a couple of simple cases out = of the many different scenarios. [Med] Please note that I used =93good/bad deployment choices=94 in the = initial message. Merging the requests will induce some complexity at the = gateway, sure. From a protocol standpoint, I=92m trying to be neutral on this. My = main concern is to avoid making choices in the protocol that will have = deployment implications. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi all,=20 =20 To avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called =93client-identifier=94. The design allows this = parameter to carry multiple values.=20 =20 Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of multiple = values.=20 =20 The potential deployment cases for multiple values are (without making = any assumption whether these cases are good/bad deployment choices): =20 (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also = cases where multiple DOTS gateways are involved.=20 (2)Requests from multiple clients may be aggregated by the same = server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. =20 =20 The current approach has the merit to not make any assumption on the = gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:=20 =20 Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers = of clients, not gateways.=20 - On-path gateways may include a new parameter called =91gateway-identifier=92 to ease contexts retrieval and avoid potential collisions. =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 =20 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if = multiple gateways are on-path. The order of the values is important because the = first one will be the one pointing to the source DOTS clients.=20 =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 = (in addition to C) =20 We are seeking for feedback from the WG on which direction to take.=20 =20 Thoughts? =20 Cheers, Med =20 =20 =20 ------=_NextPart_000_02B2_01D3780F.91E5DEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon2].

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 18 December 2017 = 14:27
To: Jon Shallow; dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] =
Envoy=E9 : lundi 18 d=E9cembre 2017 = 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; = kaname nishizuka
Objet : RE: [Dots] client-identifier: = Recurisve signaling & = Aggregation

 

Hi Med,

 

Going in the right = direction, but see comments inline [Jon1].

 

As a side comment, I = always have to think twice what “DOTS gateway server-side” = actually means.  It actually means the DOTS client component = logic of a DOTS gateway.  There is no definition of terms in the = signal channel draft, but the definition could perhaps be added to the = dots requirements draft.  Others may also get confused about = this.  Perhaps “DOTS gateway server-facing-side” is = clearer, even though much longer to type!

 

[Med] We do have the following definition in = the requirements I-D:

 

      = Client-side DOTS gateways

      are = DOTS gateways that are in the DOTS client's domain, = while

      = server-side DOTS gateways denote DOTS gateways that are in = the

      = DOTS server's = domain.

 

 

[Jon2] Yes – = actually, this adds to the confusion in my mind.=A0 For a singular DOTS = gateway, it could have a client-facing-side that is in the DOTS client = domain, and a server-facing side that is in a different DOTS server = domain.=A0 The quoted text implies it is one or the other, but not = both.

 

[Jon2] Also, being = picky, does “Client-side DOTS gateway” (type of DOTS = gateway) actually mean the same as “DOTS gateway = client-side” (component within a DOTS = gateway)?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 13:04
To: Jon Shallow; = dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Jon,

 

Please see below two proposed changes to = hopefully conclude on the issues discussed in this = thread:

 

1st change: =

 

OLD:

   = client-identifier:  The client identifier MAY be conveyed by the = DOTS

      = gateway to propagate the DOTS client identity from the = gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server.  This allows the DOTS server = to

      = accept mitigation requests with scopes which the DOTS client = is

     autho= rized to manage.

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      in = a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  The = DOTS

      = gateway MUST conceal potentially sensitive DOTS client = identity

      = information.  The client-identifier attribute SHOULD NOT = be

      = generated and included by the DOTS client.

 

      = This is an optional attribute.

 

NEW:

   = client-identifier:  The client identifier MAY be conveyed by = a

      = server-side DOTS gateway to propagate the DOTS client = identity

      = from the gateway's client-side to the gateway's server-side, = and

      = from the gateway's server-side to the DOTS server. = 'client-

      = identifier' MAY be used by the final DOTS server for = policy

      = enforcement purposes.

 

      The = 'client-identifier' value MUST be assigned by the = server-side

[Jon1]  Actually, = as the client and server components of a DOTs gateway are separate (the = server-facing component has no real knowledge of what is happening on = the client-facing side), it needs to be the client-facing-side of the = DOTS gateway that assigns the (unique) client-identifier which is then = passed over to the server-facing-side for onward = transmission.

 

[Med] You are right if = we zoom on the internal implementation of a DOTS gateway. This part of = the text focuses on the external behavior of the DOTS gateway. The text = does not need to zoom in given that the second sentence above says; =

 <= /p>

[Jon2] In terms of = helping the implementers, the use of only DOTS server being allowed to = generate a ‘client-identifier’ as discussed later.=A0 If = “server-side” was removed as in :-

“client-identifier:= =A0 The client identifier MAY be conveyed by a

=A0=A0=A0=A0=A0 DOTS = gateway to propagate the DOTS client identity = …”

Removes a = lot of confusion in my mind.

 

“to propagate the DOTS client = identity from the gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server. ”

 

      = DOTS gateway in a manner that ensures that there is = zero

      = probability that the same value will be assigned to a = different

      = DOTS client.  The server-side DOTS gateway MUST = conceal

      = potentially sensitive DOTS client identity = information.

 

      If = aggregating DOTS mitigation requests received from = multiple

      = DOTS clients is enabled, the server-side DOTS gateway has to = include

      a = list of 'client-identifier' values; each value is pointing to = a

      = DOTS client.  It is out of scope of this document to specify = how

[Jon1] I prefer “a = list of 'client-identifier' values; each value is pointing to a = unique

    &= nbsp; DOTS client that is in the aggregated list.  It is out = of….”

 

[Med] Deal. =  

 

      = aggregation is implemented by a DOTS gateway.

 

      The = client-identifier attribute MUST NOT be generated and = included

      by = DOTS clients.

 

      = DOTS servers MUST ignore client-identifier attributes that = are

      = directly supplied by source DOTS clients.  This implies that = first

      = server-side DOTS gateways MUST strip client-identifier = attributes

      = supplied by DOTS clients.

[Jon1] How do we = differentiate between an actual DOTS client and the client component of = a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server?  = There is nothing that I have spotted for this in the DOTS signal = protocol.

 

[Med] I confirm, there = is no such text in the draft. A deployment would consist in explicitly = configuring a list of gateways (ACLs) on the server; the server will = trust client-id if and only if it is coming from a server-side gateways = in that list.

 <= /p>

[Jon2] Then do we need = to instruct the implementers of the signal channel that this is what = should be done?

[Jon1] I do agree that = true DOTS clients MUST NOT generate ‘client-identifiers’. If = only the DOTS gateway server component (client-facing-side) is allowed = to generate the client-identifier (for possible onward forwarding), this = gets around this issue as it is only the DOTS server component who is = allowed to do the generation.

 <= /p>

[Jon1] In my = implementation the DOTS server (gateway or not) always generates a = client-identifier (will be changed if there already is a unique = identifier following this discussion) which is associated with a = mitigation-id etc. so that the DOTS server can differentiate between the = same mitigation-id from different clients.

[Med] Ok, = thanks.

 

      = This is an optional attribute.

 

2nd change: Delete this text = because client-identifier is uniquely assigned by the first server-side = gateway; there is no need to prepend identifiers computed by other = gateways.

 

OLD:

   If the = 'client-identifier' value is already present in = the

   mitigation request = received from the DOTS client, the DOTS gateway

   MAY compute the = 'client-identifier' value, as discussed above, = and

   add the computed = 'client-identifier' value to the end of the = 'client-

   identifier' = list.

[Jon1] OK =

 

Comments and modifications are more welcome. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de mohamed.boucadair@orange.com=
Envoy=E9 : lundi 18 d=E9cembre 2017 = 13:28
=C0 : Jon Shallow; dots@ietf.org; kaname = nishizuka
Objet : Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi Med / = Kaname,

 

“I = propose making it "MUST NOT":
The client-identifier attribute MUST NOT = be
      generated and included by the DOTS = client.”

We do need to handle the case of a broken client = (how does the DOTS server know it is a DOTS gateway client or a real = DOTS client?) who does not obey the MUST.

[Med] …but broken clients may = communicate directly with servers without any gateway on the path. =

 

“The = client-identifier attribute SHOULD NOT be generated and included by the = DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.”

 

Is the safer option for = me.

 

[Med] Actually,

=B7         = (R1) we do need MUST so that as a general rule = clients do not insert a client-id parameter in their requests. =

=B7         = And (R2) DOTS servers MUST ignore client-ids = that are supplied by the origin DOTS clients.

 

In deployments without gateways, client-ids = supplied by broken DOTS clients will be ignored by the server as per R2. =

In deployments with gateways, the first = server-side gateway will follow R2 and strip any value supplied by the = client.

 

If we add text to cover (R2), I don’t = think we need a sentence about updating the content because client-id is = a value that is ***assigned*** exclusively by a dots = gateway:

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      = ;            =             &= nbsp;     = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   =

      = ;in a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  =

 

Otherwise, see [Jon] inline (8 = times).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 06:59
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Jon,

 

Thank you for sharing your thoughts. =

 

Please see comments = inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : samedi 16 d=E9cembre 2017 = 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”

[Med] There are also some complications even = when no aggregation is in use. See below.

 

.  I am leaning = towards your Option 2.  Some of my reasoning is = below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

       &nb= sp;           &nbs= p;            = ;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS client (C1ax) ----- (S1x) DOTS gateway = X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)    =

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  |         &= nbsp;           &n= bsp;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway = Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOTS forwarding = path will always be the same (that is, the same set of gateways will be = solicited for requests coming from a given DOTS = client).

 

[Jon] The current text = states “If the 'client-identifier' value is already present in = the

   = mitigation request received from the DOTS client, the DOTS = gateway

   = MAY compute the 'client-identifier' value, as discussed above, = and

   = add the computed 'client-identifier' value to the end of the = 'client-

   identifier' = list.”

 

[Jon]  The MAY is = not a MUST for the simple reason that if the original DOTS client = client-identifier is computed correctly, it should be unique all the way = through the different DOTS gateways (so no additional client-identifiers = need to get added) so that S3 just sees = [alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS = gateways in the path can then change over time with no = issues.

 

[Jon] All that is = required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional = client-identifiers (but still adds in the first one if the first DOTS = gateway).

[Med] Agree for the first server-side gateway. =

 

[Jon] NOTE: A DOTS = gateway can elect to not add in any client-identifier – even if it = is the first in the chain if it wants to hide the client information, = but this will potentially cause information differentiation issues at = the DOTS server and I would not recommend it as client-identifiers, if = created properly, obfuscate the actual client information.

 

[Med]I do see some implications of this design in a = multi-homing scenario with the same mitigation provider: the same = request from a multi-homed DOTS client will be presented to the server = as being distinct requests…while this is not. It may be the same = request that is forked among existent network attachments or a request = that is sent over a first link, but a subsequent one over another = link.

 

[Jon] Perhaps I am = missing something here, but I would be expecting a multi-homed device to = be using the same PKI certificate (or equivalent) in which case the = client-identifier (which is not IP based) would be the same over the = different network interfaces. 

[Med] I’m referring to this = “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

 

[Jon] If however, the = different network interfaces are connected to different DOTS provider = domains, then there will be multiple PKI certs, and hence different = client-identifiers propagating up to the DOTS servers – but as = these are different provider domains will they ever join up into a = common domain?  If they do, then this is where you could be getting = conflicting requests – subject of another = discussion.

[Med] Sure, these are deployment-specific. My = concern is to avoid design choices that make hidden assumptions. =  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation). =    

 

[Jon] Yes – the = assumption being that all the client-identifiers are unique – In = which case I argue again that additional information – e.g. = gateway-identifiers are irrelevant (and also are useless when there are = multiple paths through the DOTS gateways as you refer to = above).

[Med] If we agree that one (unique) client-id = is supplied, then I’m fine.

 

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 = can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

[Med] Agree.

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

[Med] I guess you meant “restrict the = number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would = say this is deployment-specific. A deployment that enables signal/data = channel aggregation is aware of this limitation. =

 

[Jon] Yes, that is = better phrasing.

[Med] OK.

 

  I still struggle = with how do you actually do the aggregation (merging of data/signal) at = any gateway other than in a couple of simple cases out of the many = different scenarios.

[Med] Please note that I used = “good/bad = deployment choices” in the initial message. Merging the = requests will induce some complexity at the gateway, sure. From a = protocol standpoint, I’m trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have = deployment implications.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the = server select the appropriate policy to enforce, signal/data channel = protocol drafts specify a parameter called = “client-identifier”. The design allows this parameter to = carry multiple values.

 

Putting aside the extensibility argument of the data = model, the signal/data channel protocol drafts are silent about the = exact use of multiple values.

 

The potential deployment cases for multiple values are = (without making any assumption whether these cases are good/bad = deployment choices):

 

(1)Multiple = gateways may be on path. For example, draft-ietf-dots-architecture = discusses recursive signaling and also cases where multiple DOTS = gateways are involved.

(2)Requests = from multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The current approach has the merit to not make any = assumption on the gateway behavior (e.g., (2)), but it leads to a = confusion. For example, a DOTS server does not know whether multiple = client-ids supplied in a messages refer to multiple DOTS clients or to a = DOTS client and a set of on-path gateways. The protocol documents need = to be updated to avoid such confusion. Two options are listed below: =

 

Option 1 (Avoid making any assumption on gateways/proper = semantic distinction between clients and on-path = gateways)

-    Restrict the usage of ‘client-identifier’ to = carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘gateway-identifier’ pointing to = G1

 

Option 2 (Describe what a gateway cannot = do)

-    Update the architecture document to indicate that requests = are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values = only and only if multiple gateways are on-path. The order of the values = is important because the first one will be the one pointing to the = source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘client-identifier’ pointing to G1 = (in addition to C)

 

We are seeking for feedback from the WG on which direction = to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_02B2_01D3780F.91E5DEC0-- From nobody Mon Dec 18 06:59:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F1312D777 for ; Mon, 18 Dec 2017 06:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1iRoljkrTfY for ; Mon, 18 Dec 2017 06:59:48 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E51124B17 for ; Mon, 18 Dec 2017 06:59:48 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQwtO-0004Kf-LX for ietf-supjps-dots@ietf.org; Mon, 18 Dec 2017 14:59:46 +0000 From: "Jon Shallow" To: Date: Mon, 18 Dec 2017 14:59:47 -0000 Message-ID: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C8_01D37810.D8EEE0E0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdN4ENbheXtf5t9VRkK1cf1kUKfP+A== Archived-At: Subject: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:59:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C8_01D37810.D8EEE0E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, There has been a lot of discussion on this, culminating in an update in draft-ietf-dots-signal-channel-13 where 'config-interval' has been added in to try to handle the different concerns. >From my trying to simplify things perspective:- 1. NAT devices usually allow outbound session requests (source IP nat'ing) and allow for a response to come back within a defined time frame (lots of discussion on this time frame - eventually setting on 30 seconds as a good compromise - but could be longer). 2. NAT devices may be configured to allow inbound session requests (port redirection) and allow for a response to come back within a defined time frame. Doing this does raise security policy issues as this potentially allows uncontrolled access from the Internet to an internal device. 3. NAT devices are likely to break any server initiated heartbeats if the server request frequency is longer than a NAT session is maintained in the NAT device, and inbound session requests are disabled (for security reasons). 4. The frequency of Heartbeats ideally are different between peace time and attack. In peace time there could be no heartbeats or at a slow rate to keep the signal channel alive. In attack time, 30 seconds appears to be the agreed compromise time, but this is also influenced by the underlying COAP protocol (retry intervals and counters etc.). In attack time, the rate should be sufficient to detect any transmission issues within a reasonable time frame. 5. For DOTS clients, there should be no issues with heartbeats going through NAT devices (other than during an attack where there may be packet loss) no matter what the heartbeat frequency is. 6. For DOTS servers dropping the heartbeat rate below that of the active NAT session time will cause issues if there is a NAT device that does not allow inbound initiated sessions. 7. If heartbeats are in use, then both DOTS server and DOTS client have to do their separate heartbeats for network connectively / DOTS agent availability. 8. If heartbeats are being used, the DOTS server can optionally trigger mitigation is heartbeats stop working To give the ability to change the heartbeat rates, 'config-interval' has been added to the signal draft. A client then knows when to re-request the configuration (e.g. for potentially changed heartbeat values). However, 'config-interval' has to be sufficiently large to not compete with the heartbeat rate (if they both were for the same interval, then configuration update requests would effectively be doing the same task as heartbeats!). But if 'config-interval' is too large (signal draft-13 example has it as 24 minutes) then it could take time for the heartbeat rate to get increased in attack time (and if the config update response packet does not get through, it will not get updated). I think 'config-interval' needs to be thought through further. I have 2 proposals here A. If the heartbeat frequency is below that of the NAT session inactive timeout, the DOTS client will always transmit the heartbeats at the appropriate frequency. When the heartbeat request arrives at the DOTS server, this triggers a heartbeat process on the DOTS server to then heartbeat test the DOTS client. Thus the DOTS server can use the "warm" NAT session during peacetime. If the heartbeat requests do not come in from the DOTS client (and a peacetime heartbeat rate is configured) then auto-mitigation can get invoked if required. B. There are defined two heartbeat rates - one for when one or more mitigation requests are in progress (attack situations) and a second rate for peace time (can be 0 (no heartbeats) or some long timeout). Whenever the first mitigation is requested over a DOTS session, both ends start heart-beating at the "attack" rate. This gets rid of any potential 'config-interval' refresh delays / 'new heartbeat interval' packets getting lost. When there are no more mitigations active for that DOTS session, then the DOTS session drops immediately back into the peacetime values. 'config-interval' could then be replaced with 'peace-time-heartbeat-interval'. Regards Jon ------=_NextPart_000_02C8_01D37810.D8EEE0E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

There has been a lot of discussion on this, = culminating in an update in draft-ietf-dots-signal-channel-13 where = ‘config-interval’ has been added in to try to handle the = different concerns.

 

From my = trying to simplify things perspective:-

 

1. NAT = devices usually allow outbound session requests (source IP = nat’ing) and allow for a response to come back within a defined = time frame (lots of discussion on this time frame – eventually = setting on 30 seconds as a good compromise – but could be = longer).

 

2. NAT devices may be configured to allow inbound = session requests (port redirection) and allow for a response to come = back within a defined time frame.  Doing this does raise security = policy issues as this potentially allows uncontrolled access from the = Internet to an internal device.

 

3. NAT = devices are likely to break any server initiated heartbeats if the = server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security = reasons).

 

4. The frequency of Heartbeats ideally are different = between peace time and attack.  In peace time there could be no = heartbeats or at a slow rate to keep the signal channel alive.  In = attack time, 30 seconds appears to be the agreed compromise time, but = this is also influenced by the underlying COAP protocol  (retry = intervals and counters etc.).  In attack time, the rate should be = sufficient to detect any transmission issues within a reasonable time = frame.

 

5. For DOTS clients, there should be no issues with = heartbeats going through NAT devices (other than during an attack where = there may be packet loss) no matter what the heartbeat frequency = is.

 

6. For DOTS servers dropping the heartbeat rate below = that of the active NAT session time will cause issues if there is a NAT = device that does not allow inbound initiated sessions.

 

7. If = heartbeats are in use, then both DOTS server and DOTS client have to do = their separate heartbeats for network connectively / DOTS agent = availability.

 

8. If heartbeats are being used, the DOTS server can = optionally trigger mitigation is heartbeats stop = working

 

To give the ability to change the heartbeat rates, = ‘config-interval’ has been added to the signal draft.  = A client then knows when to re-request the configuration (e.g. for = potentially changed heartbeat values).  However, = ‘config-interval’ has to be sufficiently large to not = compete with the heartbeat rate (if they both were for the same = interval, then configuration update requests would effectively be doing = the same task as heartbeats!).  But if = ‘config-interval’ is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get = increased in attack time (and if the config update response packet does = not get through, it will not get updated).  I think = ‘config-interval’ needs to be thought through = further.

 

I have 2 proposals here

 

A. If the = heartbeat frequency is below that of the NAT session inactive timeout, = the DOTS client will always transmit the heartbeats at the appropriate = frequency.  When the heartbeat request arrives at the DOTS server, = this triggers a heartbeat process on the DOTS server to then heartbeat = test the DOTS client.  Thus the DOTS server can use the = “warm” NAT session during peacetime.  If the heartbeat = requests do not come in from the DOTS client (and a peacetime heartbeat = rate is configured) then auto-mitigation can get invoked if = required.

 

B. There are defined two heartbeat rates – one = for when one or more mitigation requests are in progress (attack = situations) and a second rate for peace time (can be 0 (no heartbeats) = or some long timeout).  Whenever the first mitigation is requested = over a DOTS session, both ends start heart-beating at the = “attack” rate.   This gets rid of any potential = ‘config-interval’ refresh delays / ‘new heartbeat = interval’ packets getting lost.  When there are no more = mitigations active for that DOTS session, then the DOTS session drops = immediately back into the peacetime values.  = ‘config-interval’ could then be replaced with = ‘peace-time-heartbeat-interval’.

 

Regards

 

Jon

 

 

------=_NextPart_000_02C8_01D37810.D8EEE0E0-- From nobody Mon Dec 18 07:04:50 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAECA127369 for ; Mon, 18 Dec 2017 07:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WckIdSuXbeMo for ; Mon, 18 Dec 2017 07:04:46 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30695126C26 for ; Mon, 18 Dec 2017 07:04:46 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQwyC-0004LB-NW; Mon, 18 Dec 2017 15:04:44 +0000 From: "Jon Shallow" To: , , References: <151326411899.6067.16079347190768583372@ietfa.amsl.com> <92fe250d-3d92-451a-b2f3-27865df96876@OPEXCLILM23.corporate.adroot.infra.ftgroup> <5580a619-3ceb-4d35-9906-b16ff55b922f@OPEXCLILM22.corporate.adroot.infra.ftgroup> In-Reply-To: <5580a619-3ceb-4d35-9906-b16ff55b922f@OPEXCLILM22.corporate.adroot.infra.ftgroup> Date: Mon, 18 Dec 2017 15:04:45 -0000 Message-ID: <02dd01d37811$8a95b300$9fc11900$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQKaBbv4dORxB1jG5uU4dVN883zowQHhC5U4Ajg1s5mhm0x70A== Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-signal-channel-13.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 15:04:49 -0000 Hi Med, I am struggling to get my mind around 'config-interval' and the = practical use of it as it adds in delays to changing heartbeat values. Please see my comments in the discussion "[Dots] Signal Channel = Heartbeats" I have just started. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 07:15 To: dots@ietf.org Cc: JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: = draft-ietf-dots-signal-channel-13.txt Hi all,=20 There is an error in -13 about CBOR major key for acl-name. The required change to fix it is as follows: OLD: | Parameter name | CBOR key | CBOR major type of value | +----------------------+----------------+--------------------------+ | acl-name | 42 | 2 | NEW: | Parameter name | CBOR key | CBOR major type of value | +----------------------+----------------+--------------------------+ | acl-name | 42 | 3 | Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9=A0: jeudi 14 d=E9cembre 2017 = 16:21 =C0=A0:=20 > dots@ietf.org Cc=A0: JACQUENET Christian IMT/OLN Objet=A0: [Dots] TR: = I-D=20 > Action: draft-ietf-dots-signal-channel-13.txt >=20 > Hi all, >=20 > A new version is out! >=20 > The main changes are as follows: > - Integrate the detailed comments from Christian. Many thanks to him! > - Double check the normative language. > - Add NEW text to discuss considerations related to the presence of=20 > translators > - Remove target-ip because it is redundant with target-prefix > - Update the text to indicate the required behavior for=20 > inserting/removing client-identifier by gateways > - Update the text to clearly specify the error codes to be returned > - Add a new parameter called "config-interval" to force a dots client=20 > to retrieve new config from the server. This is particularly useful=20 > for a DOTS server that want to instruct a client to reduce the=20 > frequency of heartbeat or even to cease them. > - heartbeat-interval can now be set to '0' > - Update the YANG module > - Add a pointer to the mechanisms required to prevent replay attack=20 > when > TLS1.3 0-RTT is in use. >=20 > As usual, feel free to review and share comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet-=20 > > drafts@ietf.org Envoy=E9=A0: jeudi 14 d=E9cembre 2017 16:09 =C0=A0:=20 > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action:=20 > > draft-ietf-dots-signal-channel-13.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of=20 > > the IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-13.txt > > Pages : 77 > > Date : 2017-12-14 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and = configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned = to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > o This RFC > > > > Please update TBD statements with the port number to be assigned = to > > DOTS Signal Channel Protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel > > -13 > > > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-13 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at=20 > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Dec 18 07:13:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B22A1201F8 for ; Mon, 18 Dec 2017 07:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVqPjyQVuBbx for ; Mon, 18 Dec 2017 07:13:35 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6011C1270AC for ; Mon, 18 Dec 2017 07:13:34 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 3F62A60B86; Mon, 18 Dec 2017 16:13:33 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 15443180050; Mon, 18 Dec 2017 16:13:33 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 16:13:32 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTEToHtDpwCg83imAA== Date: Mon, 18 Dec 2017 15:13:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> In-Reply-To: <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09A2A1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 15:13:38 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09A2A1OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 15:51 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, See inline [Jon2]. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 14:27 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, Going in the right direction, but see comments inline [Jon1]. As a side comment, I always have to think twice what "DOTS gateway server-s= ide" actually means. It actually means the DOTS client component logic of = a DOTS gateway. There is no definition of terms in the signal channel draf= t, but the definition could perhaps be added to the dots requirements draft= . Others may also get confused about this. Perhaps "DOTS gateway server-f= acing-side" is clearer, even though much longer to type! [Med] We do have the following definition in the requirements I-D: Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. [Jon2] Yes - actually, this adds to the confusion in my mind. For a singul= ar DOTS gateway, it could have a client-facing-side that is in the DOTS cli= ent domain, and a server-facing side that is in a different DOTS server dom= ain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for th= e "client-facing side" of a gateway to belong to the client domain and its = "server-facing side" to belong to the server domain? [Jon2] Also, being picky, does "Client-side DOTS gateway" (type of DOTS gat= eway) actually mean the same as "DOTS gateway client-side" (component withi= n a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - "xxx-side DOTS gateway" means this is owned and operated by xxx. - "DOTS gateway client-side" refers to the client-facing interface of a = DTOS gateway. It applies for both client- and server-side getaways. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway are= separate (the server-facing component has no real knowledge of what is hap= pening on the client-facing side), it needs to be the client-facing-side of= the DOTS gateway that assigns the (unique) client-identifier which is then= passed over to the server-facing-side for onward transmission. [Med] You are right if we zoom on the internal implementation of a DOTS gat= eway. This part of the text focuses on the external behavior of the DOTS ga= teway. The text does not need to zoom in given that the second sentence abo= ve says; [Jon2] In terms of helping the implementers, the use of only DOTS server be= ing allowed to generate a 'client-identifier' as discussed later. If "serv= er-side" was removed as in :- "client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity ..." Removes a lot of confusion in my mind. [Med] The "server-side" is important because we don't want client-side GWs = to reveal the identity of internal dots clients. "to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. " DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer "a list of 'client-identifier' values; each value is pointi= ng to a unique DOTS client that is in the aggregated list. It is out of...." [Med] Deal. aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the client= component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS se= rver? There is nothing that I have spotted for this in the DOTS signal pro= tocol. [Med] I confirm, there is no such text in the draft. A deployment would con= sist in explicitly configuring a list of gateways (ACLs) on the server; the= server will trust client-id if and only if it is coming from a server-side= gateways in that list. [Jon2] Then do we need to instruct the implementers of the signal channel t= hat this is what should be done? [Med] What about adding this text: NEW: DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifi= ers'. If only the DOTS gateway server component (client-facing-side) is all= owed to generate the client-identifier (for possible onward forwarding), th= is gets around this issue as it is only the DOTS server component who is al= lowed to do the generation. [Jon1] In my implementation the DOTS server (gateway or not) always generat= es a client-identifier (will be changed if there already is a unique identi= fier following this discussion) which is associated with a mitigation-id et= c. so that the DOTS server can differentiate between the same mitigation-id= from different clients. [Med] Ok, thanks. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09A2A1OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 15:51
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuk= a
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

See inl= ine [Jon2].

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 14:27
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

Going i= n the right direction, but see comments inline [Jon1].

&n= bsp;

As a si= de comment, I always have to think twice what “DOTS gateway server-si= de” actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definiti= on of terms in the signal channel draft, but the definition could perhaps b= e added to the dots requirements draft.  Others may also get confused = about this.  Perhaps “DOTS gateway server-facing-side” is clearer, even though much longer to type!

 

[Med] We do h= ave the following definition in the requirements I-D:

 

&= nbsp;     Client-side DOTS gateways

&= nbsp;     are DOTS gateways that are in the DOTS client= 's domain, while

&= nbsp;     server-side DOTS gateways denote DOTS gateway= s that are in the

&= nbsp;     DOTS server's domain.=

&n= bsp;

&n= bsp;

[Jon2] = Yes – actually, this adds to the confusion in my mind.  For a si= ngular DOTS gateway, it could have a client-facing-side that is in the DOTS= client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one= or the other, but not both.

[Med] Do you = have a particular case in mind in which we should allow for the “clie= nt-facing side” of a gateway to belong to the client domain and its “server-facing side” to belong to the server domain? =

&n= bsp;

[Jon2] = Also, being picky, does “Client-side DOTS gateway” (type of DOT= S gateway) actually mean the same as “DOTS gateway client-side”= (component within a DOTS gateway)?

[Med] No. Tho= se are two distinct things/dimensions:

-    ̶= 0;xxx-side DOTS gateway” means this is owned and operated by xxx.

-    ̶= 0;DOTS gateway client-side” refers to the client-facing interface of = a DTOS gateway. It applies for both client- and server-side getaways.  

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 13:04
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Jon,

 

Please see be= low two proposed changes to hopefully conclude on the issues discussed in t= his thread:

 

1st change:

 

OLD:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by the DOTS

&= nbsp;     gateway to propagate the DOTS client identity= from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server.  This al= lows the DOTS server to

&= nbsp;     accept mitigation requests with scopes which = the DOTS client is

&= nbsp;    authorized to manage.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;     in a manner that ensures that there is zero p= robability that the

&= nbsp;     same value will be assigned to a different DO= TS client.  The DOTS

&= nbsp;     gateway MUST conceal potentially sensitive DO= TS client identity

&= nbsp;     information.  The client-identifier attr= ibute SHOULD NOT be

&= nbsp;     generated and included by the DOTS client.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

NEW:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by a

&= nbsp;     server-side DOTS gateway to propagate the DOT= S client identity

&= nbsp;     from the gateway's client-side to the gateway= 's server-side, and

&= nbsp;     from the gateway's server-side to the DOTS se= rver. 'client-

&= nbsp;     identifier' MAY be used by the final DOTS ser= ver for policy

&= nbsp;     enforcement purposes.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the server-side

[Jon1]  Actually, as the client and server components= of a DOTs gateway are separate (the server-facing component has no real kn= owledge of what is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assi= gns the (unique) client-identifier which is then passed over to the server-= facing-side for onward transmission.

 

[Med] You are right if we zoom on the internal implementation of= a DOTS gateway. This part of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that= the second sentence above says;

 

[Jon2] In terms of helping the implementers, the use of on= ly DOTS server being allowed to generate a ‘client-identifier’ = as discussed later.  If “server-side” was removed as in :-

“client-identifier:&nbs= p; The client identifier MAY be conveyed by a

      DOTS gateway to propagate t= he DOTS client identity …”

Removes a lot of confusion in my mind.

 

[Med] The “server-side” is important because we don&= #8217;t want client-side GWs to reveal the identity of internal dots client= s.

 

 

“to propagate the DOTS client identity from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server. ”

 

&= nbsp;     DOTS gateway in a manner that ensures that th= ere is zero

&= nbsp;     probability that the same value will be assig= ned to a different

&= nbsp;     DOTS client.  The server-side DOTS gatew= ay MUST conceal

&= nbsp;     potentially sensitive DOTS client identity in= formation.

<= o:p> 

&= nbsp;     If aggregating DOTS mitigation requests recei= ved from multiple

&= nbsp;     DOTS clients is enabled, the server-side DOTS= gateway has to include

&= nbsp;     a list of 'client-identifier' values; each va= lue is pointing to a

&= nbsp;     DOTS client.  It is out of scope of this= document to specify how

[Jon1] I prefer “a list of 'client-identifier' value= s; each value is pointing to a unique

      DOTS client that is in the = aggregated list.  It is out of….”

 

[Med] Deal.  

 

&= nbsp;     aggregation is implemented by a DOTS gateway.=

<= o:p> 

&= nbsp;     The client-identifier attribute MUST NOT be g= enerated and included

&= nbsp;     by DOTS clients.

<= o:p> 

&= nbsp;     DOTS servers MUST ignore client-identifier at= tributes that are

&= nbsp;     directly supplied by source DOTS clients.&nbs= p; This implies that first

&= nbsp;     server-side DOTS gateways MUST strip client-i= dentifier attributes

&= nbsp;     supplied by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS clie= nt and the client component of a DOTS gateway (i.e. server-facing-side) as = seen by a DOTS server?  There is nothing that I have spotted for this in the DOTS signal protocol.

 

[Med] I confirm, there is no such text in the draft. A deploymen= t would consist in explicitly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is= coming from a server-side gateways in that list.

 

[Jon2] Then do we need to instruct the implementers of the= signal channel that this is what should be done?

[Med] What about adding this text:

 

NEW:

&= nbsp;     DOTS servers MAY support a

&= nbsp;     configuration parameter (e.g., ACLs) to ident= ify DOTS gateways

&= nbsp;     that are trusted to supply client-identifier = attributes.

 

 

[Jon1] I do agree that true DOTS clients MUST NOT generate= ‘client-identifiers’. If only the DOTS gateway server componen= t (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this = issue as it is only the DOTS server component who is allowed to do the gene= ration.

 

[Jon1] In my implementation the DOTS server (gateway or no= t) always generates a client-identifier (will be changed if there already i= s a unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can = differentiate between the same mitigation-id from different clients.

[Med] Ok, thanks.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

2nd change: Delete this text because client-identifier is uniquely assigned b= y the first server-side gateway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

&= nbsp;  If the 'client-identifier' value is already present in the=

&= nbsp;  mitigation request received from the DOTS client, the DOTS gate= way

&= nbsp;  MAY compute the 'client-identifier' value, as discussed above, = and

&= nbsp;  add the computed 'client-identifier' value to the end of the 'c= lient-

&= nbsp;  identifier' list.

[Jon1] OK

 

Comments and = modifications are more welcome.

 

Cheers,<= /o:p>

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.o= rg; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see in= line.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …= but broken clients may communicate directly with servers without any gatewa= y on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actuall= y,

=B7    &n= bsp;    (R1) = we do need MUST so that as a general rule clients do not insert a client-id= parameter in their requests.

=B7    &n= bsp;    And (= R2) DOTS servers MUST ignore client-ids that are supplied by the origin DOT= S clients.

 

In deployment= s without gateways, client-ids supplied by broken DOTS clients will be igno= red by the server as per R2.

In deployment= s with gateways, the first server-side gateway will follow R2 and strip any= value supplied by the client.

 

If we add tex= t to cover (R2), I don’t think we need a sentence about updating the = content because client-id is a value that is ***assigned*** exclusively by a dots gateway:

 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;           &nbs= p;            &= nbsp;          ^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^  

&= nbsp;     in a manner that ensures that there is z= ero probability that the

&= nbsp;     same value will be assigned to a different DO= TS client. 

 =

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for= sharing your thoughts.

 

Please see co= mments inline.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There a= re also some complications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client = (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ---= -------\  

DOTS client = (C1bj) ----------------------------------------/    &nb= sp;            =              &n= bsp;   |

  =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

DOTS client = (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) ---= ----- (S3)   

DOTS client = (C1bx) --------/          = ;            &n= bsp;        |   &nbs= p;            &= nbsp;            &nb= sp; 

  =             &nb= sp;            =             &nb= sp;            =        |     &n= bsp;            = ;             &= nbsp; 

DOTS client = (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/    &nb= sp;            =              &n= bsp;  

DOTS client = (C1by) --------/          = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This as= sumes that the DOTS forwarding path will always be the same (that is, the s= ame set of gateways will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree f= or the first server-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this = design in a multi-homing scenario with the same mitigation provider: the same req= uest from a multi-homed DOTS client will be presented to the server as bein= g distinct requests…while this is not. It may be the same request tha= t is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over ano= ther link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’= ;m referring to this “[alias-name=3DServer1&client-identifer=3DCI= (C1ax),CI(C2x),CI(C3k)]”.=

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, t= hese are deployment-specific. My concern is to avoid design choices that ma= ke hidden assumptions.  

 

 

[Med] Separating both client-id fro= m gateway-id does not suffer from this issue (even when no aggregation). &n= bsp;  

 =

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we a= gree that one (unique) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess= you meant “restrict the number of aggregated clients per DOTS gatewa= y”, not the “number of DOTS clients serviced by a DOTS gateway&= #8221;. I would say this is deployment-specific. A deployment that enables signal/= data channel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please = note that I used “good/bad deployme= nt choices” in the initial message. Merging the requests will induce some complexity a= t the gateway, sure. From a protocol standpoint, I’m trying to be neu= tral on this. My main concern is to avoid making choices in the protocol th= at will have deployment implications.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

- = ;   Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

- = ;   ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A09A2A1OPEXCLILMA3corp_-- From nobody Mon Dec 18 07:31:36 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF81C12D779; Mon, 18 Dec 2017 07:31:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151361109473.3491.4119944658869204153@ietfa.amsl.com> Date: Mon, 18 Dec 2017 07:31:34 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 15:31:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-11.txt Pages : 31 Date : 2017-12-18 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel"; o reference: RFC XXXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 18 07:37:32 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D8B127369 for ; Mon, 18 Dec 2017 07:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Qt_d6Jzxna for ; Mon, 18 Dec 2017 07:37:30 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14F112708C for ; Mon, 18 Dec 2017 07:37:29 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id F3D64C0A7D for ; Mon, 18 Dec 2017 16:37:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id DC028120065 for ; Mon, 18 Dec 2017 16:37:27 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 16:37:27 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQHTeBVMhUCHvARg7UWnmNPvuJtkTKNJOnpA Date: Mon, 18 Dec 2017 15:37:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> In-Reply-To: <151361109473.3491.4119944658869204153@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 15:37:31 -0000 Re-, The main changes in this version are as follows: - Remove target-ip because it is redundant with target-prefix - Indicate that the order of establishing signal/data channel is implementa= tion/deployment specific - Mention that the signal channel I-D is the authoritative reference for ma= nipulating client-id; the data channel must follow the signal channel spec.= =20 - Add a discussion about translation implications - Add conflict support - The same resource can be associated with different aliases if multiple do= ts clients are deployed within a network - Check the normative language=20 Please review and share comments.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-11.txt > Pages : 31 > Date : 2017-12-18 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. >=20 > This is a companion document to the DOTS signal channel > specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel"; >=20 > o reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-11 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Dec 18 07:45:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5197126CBF for ; Mon, 18 Dec 2017 07:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eg2nuvbw8HH for ; Mon, 18 Dec 2017 07:45:03 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570261200B9 for ; Mon, 18 Dec 2017 07:45:02 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQxb9-0004Mg-CT; Mon, 18 Dec 2017 15:44:59 +0000 From: "Jon Shallow" To: , , "kaname nishizuka" References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 18 Dec 2017 15:45:00 -0000 Message-ID: <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EF_01D37817.29DAC360" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nANCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTETAkWEwxEDVu2BwKBObuRg Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 15:45:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EF_01D37817.29DAC360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon3] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 15:14 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 15:51 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med, =20 See inline [Jon2]. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 14:27 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med, =20 Going in the right direction, but see comments inline [Jon1]. =20 As a side comment, I always have to think twice what =93DOTS gateway server-side=94 actually means. It actually means the DOTS client = component logic of a DOTS gateway. There is no definition of terms in the signal channel draft, but the definition could perhaps be added to the dots requirements draft. Others may also get confused about this. Perhaps = =93DOTS gateway server-facing-side=94 is clearer, even though much longer to = type! =20 [Med] We do have the following definition in the requirements I-D:=20 =20 Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. =20 =20 [Jon2] Yes =96 actually, this adds to the confusion in my mind. For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for = the =93client-facing side=94 of a gateway to belong to the client domain and = its =93server-facing side=94 to belong to the server domain?=20 [Jon3]The recursive gateway comes immediately to mind =96 when an ISP = cannot handle the current attack and wants to invoke someone else to handle it. Otherwise to me, a gateway to me is either an aggregation point of = clients within a common domain or a border between two different domains. =20 [Jon2] Also, being picky, does =93Client-side DOTS gateway=94 (type of = DOTS gateway) actually mean the same as =93DOTS gateway client-side=94 = (component within a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - =93xxx-side DOTS gateway=94 means this is owned and operated by = xxx. - =93DOTS gateway client-side=94 refers to the client-facing = interface of a DTOS gateway. It applies for both client- and server-side getaways. =20 [Jon3] I agree with your distinct definitions, but not the use of the definition in the requirements I-D to cover the definition of =93DOTS = Gateway client-side=94 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Jon,=20 =20 Please see below two proposed changes to hopefully conclude on the = issues discussed in this thread: =20 1st change:=20 =20 OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. =20 The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. =20 This is an optional attribute. =20 NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. =20 The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway = are separate (the server-facing component has no real knowledge of what is happening on the client-facing side), it needs to be the = client-facing-side of the DOTS gateway that assigns the (unique) client-identifier which is then passed over to the server-facing-side for onward transmission. =20 [Med] You are right if we zoom on the internal implementation of a DOTS gateway. This part of the text focuses on the external behavior of the = DOTS gateway. The text does not need to zoom in given that the second = sentence above says;=20 =20 [Jon2] In terms of helping the implementers, the use of only DOTS server being allowed to generate a =91client-identifier=92 as discussed later. = If =93server-side=94 was removed as in :- =93client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity =85=94 Removes a lot of confusion in my mind. =20 [Med] The =93server-side=94 is important because we don=92t want = client-side GWs to reveal the identity of internal dots clients.=20 [Jon3] Why do we need to be restrictive to =93Server-side DOTS = gateways=94 here? [Jon3] =93Client-side DOTS gateways=94 may, or may not, want to pass on =93client-identifiers=94 (which are obfuscated to hide identity). If = they do not pass on =93client-identifiers=94 then the DOTS server they connect = to (which is in the same domain by definition) will not be able to differentiate between the different clients =96 the whole purpose of = =93client-identifiers=94 =96 or am I missing something here? [Jon3] To me, the only time that =93client-identifiers=94 may need to be = dropped (not that I recommend doing this) is when a DOTS Gateway is sitting in = both a client=92s domain and a different server=92s domain as a domain border gateway. =20 =20 =93to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. =94 =20 DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. =20 If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to = include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer =93a list of 'client-identifier' values; each value is pointing to a unique DOTS client that is in the aggregated list. It is out of=85.=94 =20 [Med] Deal. =20 =20 aggregation is implemented by a DOTS gateway. =20 The client-identifier attribute MUST NOT be generated and included by DOTS clients. =20 DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the = client component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server? There is nothing that I have spotted for this in the DOTS = signal protocol. =20 [Med] I confirm, there is no such text in the draft. A deployment would consist in explicitly configuring a list of gateways (ACLs) on the = server; the server will trust client-id if and only if it is coming from a server-side gateways in that list. =20 [Jon2] Then do we need to instruct the implementers of the signal = channel that this is what should be done? [Med] What about adding this text:=20 =20 NEW:=20 DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. =20 =20 [Jon1] I do agree that true DOTS clients MUST NOT generate =91client-identifiers=92. If only the DOTS gateway server component (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is only = the DOTS server component who is allowed to do the generation. =20 [Jon1] In my implementation the DOTS server (gateway or not) always generates a client-identifier (will be changed if there already is a = unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differentiate between the same mitigation-id from different clients. [Med] Ok, thanks. =20 This is an optional attribute. =20 2nd change: Delete this text because client-identifier is uniquely = assigned by the first server-side gateway; there is no need to prepend = identifiers computed by other gateways.=20 =20 OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK=20 =20 Comments and modifications are more welcome.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med / Kaname, =20 =93I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client.=94 We do need to handle the case of a broken client (how does the DOTS = server know it is a DOTS gateway client or a real DOTS client?) who does not = obey the MUST. [Med] =85but broken clients may communicate directly with servers = without any gateway on the path.=20 =20 =93The client-identifier attribute SHOULD NOT be generated and included = by the DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.=94 =20 Is the safer option for me. =20 [Med] Actually,=20 =B7 (R1) we do need MUST so that as a general rule clients do = not insert a client-id parameter in their requests.=20 =B7 And (R2) DOTS servers MUST ignore client-ids that are = supplied by the origin DOTS clients.=20 =20 In deployments without gateways, client-ids supplied by broken DOTS = clients will be ignored by the server as per R2.=20 In deployments with gateways, the first server-side gateway will follow = R2 and strip any value supplied by the client.=20 =20 If we add text to cover (R2), I don=92t think we need a sentence about updating the content because client-id is a value that is ***assigned*** exclusively by a dots gateway: =20 The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = =20 in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. =20 =20 Otherwise, see [Jon] inline (8 times). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Thank you for sharing your thoughts.=20 =20 Please see comments inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med and all, =20 I think that =91gateway-identifier=92 is likely to cause more confusion = and will not actually help to try and solve what I perceive is the underlying = issue that has triggered this discussion - =93How do we handle = =91client-identifiers=92 when a DOTS gateway does aggregation?=94 [Med] There are also some complications even when no aggregation is in = use. See below.=20 =20 . I am leaning towards your Option 2. Some of my reasoning is below. =20 Background to client-identifiers. =20 In the general case (e.g. no DOTS gateway aggregation of filters / = aliases etc.), every time a request or update (both signal and data) passes = upstream through a DOTS gateway, an additional =91client-identifier=92 is added = to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, = say, an (possibly non unique alias-name) alias definition sent over the data = channel with a (possibly non unique mitigation-id) mitigation request using the = same alias-name sent over the signal channel. =20 Client Identification Usage Example =20 DOTS client (C1aj) ------------------------------------- (S1j) DOTS = gateway J (C2j) ----------\ =20 DOTS client (C1bj) ----------------------------------------/ | =20 | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS = gateway K (C3k) -------- (S3) =20 DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ =20 Where CI is =91client-identifier=92 =96 a unique hash of the client = identification :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)] =20 [Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client). =20 [Jon] The current text states =93If the 'client-identifier' value is = already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list.=94 =20 [Jon] The MAY is not a MUST for the simple reason that if the original = DOTS client client-identifier is computed correctly, it should be unique all = the way through the different DOTS gateways (so no additional = client-identifiers need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C1ax)]. The DOTS gateways = in the path can then change over time with no issues. =20 [Jon] All that is required then is that a DOTS gateway makes sure that = any Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional client-identifiers = (but still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway.=20 =20 [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier = =96 even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information. =20 [Med]I do see some implications of this design in a multi-homing = scenario with the same mitigation provider: the same request from a multi-homed = DOTS client will be presented to the server as being distinct = requests=85while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a = subsequent one over another link. =20 [Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) = in which case the client-identifier (which is not IP based) would be the = same over the different network interfaces. =20 [Med] I=92m referring to this =93[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]=94.= =20 [Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, = and hence different client-identifiers propagating up to the DOTS servers = =96 but as these are different provider domains will they ever join up into a = common domain? If they do, then this is where you could be getting conflicting requests =96 subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design choices that make hidden assumptions. =20 =20 =20 [Med] Separating both client-id from gateway-id does not suffer from = this issue (even when no aggregation). =20 =20 [Jon] Yes =96 the assumption being that all the client-identifiers are = unique =96 In which case I argue again that additional information =96 e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I=92m = fine.=20 =20 so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different CI(). =20 Then when C1ax requests a mitigation with alias-name=3DServer1, by the = time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]. =20 If C1aj also requests a mitigation with alias-name=3DServer1, S3 will = see the alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] = and match accordingly. =20 As responses come back from S3 to the originating client, the = appropriate CI(cxxx) gets stripped off so the originating client sees no =91client-identifier=92 fields at all. =20 This general solution is simple with only one disadvantage =96 there is = a limit of 20 - 24 client-identifiers (20 =96 24 DOTS gateways) that will = fit into a single UDP packet due to MTU restrictions. However in practice = there are unlikely to be this number of DOTS gateways. The count varies based = on how much other information needs to be put into the packet. =20 DOTS Gateway Session aggregation =20 There is no reason as to why multiple DOTS clients=92 signal and data = requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection =96 especially as different client-identifiers = separate out the different requests / responses. =20 This session aggregation is not the same as signal / data aggregation =20 NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation =20 [Med] Agree.=20 =20 DOTS Gateway signal / data aggregation challenges =20 Individual clients in general will generate their unique mitigation = requests =96 but may have common information (e.g. same protocol, ports, = alias-name). If the mitigation requests are not unique then we have potential = conflicts =96 not part of this discussion. =20 Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes =96 aggregating different port requirements = for different target-prefixes gets more interesting=85.. This adds in a lot = of potential complexity with potential for boundary condition error issues. =20 Aggregation of Filters is at first sight relatively simple - but there = then may be ordering challenges / conflicts =96 e.g. one filter has an IP = that is a white-list, and another has the same IP as a black-list =96 both valid = in the respective client environment. Ordering of conflicting filter = information is important and I am not sure that a DOTS gateway will do this = properly unless it either has some hints or complex rules to work with =96 just = adding in complexity where more things can potentially go wrong. =20 Use of gateway-identifier and client-identifier combination can be used = to partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 =96 24 *-identifiers in total due to packet MTU. Even if = we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 =96 20. Do we = really want to restrict the number of supported DOTS clients per DOTS gateway = if aggregation is supported? =20 [Med] I guess you meant =93restrict the number of aggregated clients per = DOTS gateway=94, not the =93number of DOTS clients serviced by a DOTS = gateway=94. I would say this is deployment-specific. A deployment that enables = signal/data channel aggregation is aware of this limitation.=20 =20 [Jon] Yes, that is better phrasing. [Med] OK.=20 =20 I still struggle with how do you actually do the aggregation (merging = of data/signal) at any gateway other than in a couple of simple cases out = of the many different scenarios. [Med] Please note that I used =93good/bad deployment choices=94 in the = initial message. Merging the requests will induce some complexity at the = gateway, sure. From a protocol standpoint, I=92m trying to be neutral on this. My = main concern is to avoid making choices in the protocol that will have = deployment implications. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi all,=20 =20 To avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called =93client-identifier=94. The design allows this = parameter to carry multiple values.=20 =20 Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of multiple = values.=20 =20 The potential deployment cases for multiple values are (without making = any assumption whether these cases are good/bad deployment choices): =20 (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also = cases where multiple DOTS gateways are involved.=20 (2)Requests from multiple clients may be aggregated by the same = server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. =20 =20 The current approach has the merit to not make any assumption on the = gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:=20 =20 Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers = of clients, not gateways.=20 - On-path gateways may include a new parameter called =91gateway-identifier=92 to ease contexts retrieval and avoid potential collisions. =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 =20 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if = multiple gateways are on-path. The order of the values is important because the = first one will be the one pointing to the source DOTS clients.=20 =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 = (in addition to C) =20 We are seeking for feedback from the WG on which direction to take.=20 =20 Thoughts? =20 Cheers, Med =20 =20 =20 ------=_NextPart_000_02EF_01D37817.29DAC360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon3]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 18 December 2017 = 15:14
To: Jon Shallow; dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 15:51
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi = Med,

 

See inline = [Jon2].

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 14:27
To: Jon Shallow; = dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi = Med,

 

Going in the right = direction, but see comments inline [Jon1].

 

As a side comment, I = always have to think twice what “DOTS gateway server-side” = actually means.  It actually means the DOTS client component = logic of a DOTS gateway.  There is no definition of terms in the = signal channel draft, but the definition could perhaps be added to the = dots requirements draft.  Others may also get confused about = this.  Perhaps “DOTS gateway server-facing-side” is = clearer, even though much longer to type!

 

[Med] We do have the following definition in = the requirements I-D:

 

      = Client-side DOTS gateways

      are = DOTS gateways that are in the DOTS client's domain, = while

      = server-side DOTS gateways denote DOTS gateways that are in = the

      = DOTS server's = domain.

 

 

[Jon2] Yes – = actually, this adds to the confusion in my mind.  For a singular = DOTS gateway, it could have a client-facing-side that is in the DOTS = client domain, and a server-facing side that is in a different DOTS = server domain.  The quoted text implies it is one or the other, but = not both.

[Med] Do you have a particular case in mind in = which we should allow for the “client-facing side” of a = gateway to belong to the client domain and its “server-facing = side” to belong to the server domain?

[Jon3]The recursive = gateway comes immediately to mind – when an ISP cannot handle the = current attack and wants to invoke someone else to handle it.=A0 = Otherwise to me, a gateway to me is either an aggregation point of = clients within a common domain or a border between two different = domains.

 

[Jon2] Also, being = picky, does “Client-side DOTS gateway” (type of DOTS = gateway) actually mean the same as “DOTS gateway = client-side” (component within a DOTS = gateway)?

[Med] No. Those are two distinct = things/dimensions:

-    = “xxx-side DOTS gateway” means this = is owned and operated by xxx.

-    = “DOTS gateway client-side” refers = to the client-facing interface of a DTOS gateway. It applies for both = client- and server-side getaways.  

[Jon3] I agree with your = distinct definitions, but not the use of the definition in the = requirements I-D to cover the definition of “DOTS Gateway = client-side”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 13:04
To: Jon Shallow; = dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Jon,

 

Please see below two proposed changes to = hopefully conclude on the issues discussed in this = thread:

 

1st change: =

 

OLD:

   = client-identifier:  The client identifier MAY be conveyed by the = DOTS

      = gateway to propagate the DOTS client identity from the = gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server.  This allows the DOTS server = to

      = accept mitigation requests with scopes which the DOTS client = is

     autho= rized to manage.

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      in = a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  The = DOTS

      = gateway MUST conceal potentially sensitive DOTS client = identity

      = information.  The client-identifier attribute SHOULD NOT = be

      = generated and included by the DOTS client.

 

      = This is an optional attribute.

 

NEW:

   = client-identifier:  The client identifier MAY be conveyed by = a

      = server-side DOTS gateway to propagate the DOTS client = identity

      = from the gateway's client-side to the gateway's server-side, = and

      = from the gateway's server-side to the DOTS server. = 'client-

      = identifier' MAY be used by the final DOTS server for = policy

      = enforcement purposes.

 

      The = 'client-identifier' value MUST be assigned by the = server-side

[Jon1]  Actually, = as the client and server components of a DOTs gateway are separate (the = server-facing component has no real knowledge of what is happening on = the client-facing side), it needs to be the client-facing-side of the = DOTS gateway that assigns the (unique) client-identifier which is then = passed over to the server-facing-side for onward = transmission.

 

[Med] You are right if = we zoom on the internal implementation of a DOTS gateway. This part of = the text focuses on the external behavior of the DOTS gateway. The text = does not need to zoom in given that the second sentence above says; =

 <= /p>

[Jon2] In terms of = helping the implementers, the use of only DOTS server being allowed to = generate a ‘client-identifier’ as discussed later.  If = “server-side” was removed as in :-

“client-identifier:=   The client identifier MAY be conveyed by = a

    &= nbsp; DOTS gateway to propagate the DOTS client identity = …”

Removes a = lot of confusion in my mind.

 

[Med] The = “server-side” is important because we don’t want = client-side GWs to reveal the identity of internal dots clients. =

[Jon3] Why do we need to = be restrictive to “Server-side DOTS gateways” = here?

[Jon3] = “Client-side DOTS gateways” may, or may not, want to pass on = “client-identifiers” (which are obfuscated to hide = identity).=A0 If they do not pass on “client-identifiers” = then the DOTS server they connect to (which is in the same domain by = definition) will not be able to differentiate between the different = clients – the whole purpose of “client-identifiers” = – or am I missing something here?

[Jon3] To me, the only = time that “client-identifiers” may need to be dropped (not = that I recommend doing this) is when a DOTS Gateway is sitting in both a = client’s domain and a different server’s domain as a domain = border gateway.

 

 

“to propagate the DOTS client = identity from the gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server. ”

 

      = DOTS gateway in a manner that ensures that there is = zero

      = probability that the same value will be assigned to a = different

      = DOTS client.  The server-side DOTS gateway MUST = conceal

      = potentially sensitive DOTS client identity = information.

 

      If = aggregating DOTS mitigation requests received from = multiple

      = DOTS clients is enabled, the server-side DOTS gateway has to = include

      a = list of 'client-identifier' values; each value is pointing to = a

      = DOTS client.  It is out of scope of this document to specify = how

[Jon1] I prefer “a = list of 'client-identifier' values; each value is pointing to a = unique

    &= nbsp; DOTS client that is in the aggregated list.  It is out = of….”

 

[Med] Deal. =  

 

      = aggregation is implemented by a DOTS gateway.

 

      The = client-identifier attribute MUST NOT be generated and = included

      by = DOTS clients.

 

      = DOTS servers MUST ignore client-identifier attributes that = are

      = directly supplied by source DOTS clients.  This implies that = first

      = server-side DOTS gateways MUST strip client-identifier = attributes

      = supplied by DOTS clients.

[Jon1] How do we = differentiate between an actual DOTS client and the client component of = a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server?  = There is nothing that I have spotted for this in the DOTS signal = protocol.

 

[Med] I confirm, there = is no such text in the draft. A deployment would consist in explicitly = configuring a list of gateways (ACLs) on the server; the server will = trust client-id if and only if it is coming from a server-side gateways = in that list.

 <= /p>

[Jon2] Then do we need = to instruct the implementers of the signal channel that this is what = should be done?

[Med] What about = adding this text:

 

NEW: =

      = ;DOTS servers MAY support a

      = configuration parameter (e.g., ACLs) to identify DOTS = gateways

      = that are trusted to supply client-identifier = attributes.

 

 

[Jon1] I do agree that = true DOTS clients MUST NOT generate ‘client-identifiers’. If = only the DOTS gateway server component (client-facing-side) is allowed = to generate the client-identifier (for possible onward forwarding), this = gets around this issue as it is only the DOTS server component who is = allowed to do the generation.

 <= /p>

[Jon1] In my = implementation the DOTS server (gateway or not) always generates a = client-identifier (will be changed if there already is a unique = identifier following this discussion) which is associated with a = mitigation-id etc. so that the DOTS server can differentiate between the = same mitigation-id from different clients.

[Med] Ok, = thanks.

 

      = This is an optional attribute.

 

2nd change: Delete this text = because client-identifier is uniquely assigned by the first server-side = gateway; there is no need to prepend identifiers computed by other = gateways.

 

OLD:

   If the = 'client-identifier' value is already present in = the

   mitigation request = received from the DOTS client, the DOTS gateway

   MAY compute the = 'client-identifier' value, as discussed above, = and

   add the computed = 'client-identifier' value to the end of the = 'client-

   identifier' = list.

[Jon1] OK =

 

Comments and modifications are more welcome. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de mohamed.boucadair@orange.com=
Envoy=E9 : lundi 18 d=E9cembre 2017 = 13:28
=C0 : Jon Shallow; dots@ietf.org; kaname = nishizuka
Objet : Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi Med / = Kaname,

 

“I = propose making it "MUST NOT":
The client-identifier attribute MUST NOT = be
      generated and included by the DOTS = client.”

We do need to handle the case of a broken client = (how does the DOTS server know it is a DOTS gateway client or a real = DOTS client?) who does not obey the MUST.

[Med] …but broken clients may = communicate directly with servers without any gateway on the path. =

 

“The = client-identifier attribute SHOULD NOT be generated and included by the = DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.”

 

Is the safer option for = me.

 

[Med] Actually,

=B7         = (R1) we do need MUST so that as a general rule = clients do not insert a client-id parameter in their requests. =

=B7         = And (R2) DOTS servers MUST ignore client-ids = that are supplied by the origin DOTS clients.

 

In deployments without gateways, client-ids = supplied by broken DOTS clients will be ignored by the server as per R2. =

In deployments with gateways, the first = server-side gateway will follow R2 and strip any value supplied by the = client.

 

If we add text to cover (R2), I don’t = think we need a sentence about updating the content because client-id is = a value that is ***assigned*** exclusively by a dots = gateway:

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      = ;            =             &= nbsp;     = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   =

      = ;in a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  =

 

Otherwise, see [Jon] inline (8 = times).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 06:59
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Jon,

 

Thank you for sharing your thoughts. =

 

Please see comments = inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : samedi 16 d=E9cembre 2017 = 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”

[Med] There are also some complications even = when no aggregation is in use. See below.

 

.  I am leaning = towards your Option 2.  Some of my reasoning is = below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

       &nb= sp;           &nbs= p;            = ;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS client (C1ax) ----- (S1x) DOTS gateway = X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)    =

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  |         &= nbsp;           &n= bsp;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway = Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOTS forwarding = path will always be the same (that is, the same set of gateways will be = solicited for requests coming from a given DOTS = client).

 

[Jon] The current text = states “If the 'client-identifier' value is already present in = the

   = mitigation request received from the DOTS client, the DOTS = gateway

   = MAY compute the 'client-identifier' value, as discussed above, = and

   = add the computed 'client-identifier' value to the end of the = 'client-

   identifier' = list.”

 

[Jon]  The MAY is = not a MUST for the simple reason that if the original DOTS client = client-identifier is computed correctly, it should be unique all the way = through the different DOTS gateways (so no additional client-identifiers = need to get added) so that S3 just sees = [alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS = gateways in the path can then change over time with no = issues.

 

[Jon] All that is = required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional = client-identifiers (but still adds in the first one if the first DOTS = gateway).

[Med] Agree for the first server-side gateway. =

 

[Jon] NOTE: A DOTS = gateway can elect to not add in any client-identifier – even if it = is the first in the chain if it wants to hide the client information, = but this will potentially cause information differentiation issues at = the DOTS server and I would not recommend it as client-identifiers, if = created properly, obfuscate the actual client information.

 

[Med]I do see some implications of this design in a = multi-homing scenario with the same mitigation provider: the same = request from a multi-homed DOTS client will be presented to the server = as being distinct requests…while this is not. It may be the same = request that is forked among existent network attachments or a request = that is sent over a first link, but a subsequent one over another = link.

 

[Jon] Perhaps I am = missing something here, but I would be expecting a multi-homed device to = be using the same PKI certificate (or equivalent) in which case the = client-identifier (which is not IP based) would be the same over the = different network interfaces. 

[Med] I’m referring to this = “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

 

[Jon] If however, the = different network interfaces are connected to different DOTS provider = domains, then there will be multiple PKI certs, and hence different = client-identifiers propagating up to the DOTS servers – but as = these are different provider domains will they ever join up into a = common domain?  If they do, then this is where you could be getting = conflicting requests – subject of another = discussion.

[Med] Sure, these are deployment-specific. My = concern is to avoid design choices that make hidden assumptions. =  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation). =    

 

[Jon] Yes – the = assumption being that all the client-identifiers are unique – In = which case I argue again that additional information – e.g. = gateway-identifiers are irrelevant (and also are useless when there are = multiple paths through the DOTS gateways as you refer to = above).

[Med] If we agree that one (unique) client-id = is supplied, then I’m fine.

 

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 = can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

[Med] Agree.

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

[Med] I guess you meant “restrict the = number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would = say this is deployment-specific. A deployment that enables signal/data = channel aggregation is aware of this limitation. =

 

[Jon] Yes, that is = better phrasing.

[Med] OK.

 

  I still struggle = with how do you actually do the aggregation (merging of data/signal) at = any gateway other than in a couple of simple cases out of the many = different scenarios.

[Med] Please note that I used = “good/bad = deployment choices” in the initial message. Merging the = requests will induce some complexity at the gateway, sure. From a = protocol standpoint, I’m trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have = deployment implications.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the = server select the appropriate policy to enforce, signal/data channel = protocol drafts specify a parameter called = “client-identifier”. The design allows this parameter to = carry multiple values.

 

Putting aside the extensibility argument of the data = model, the signal/data channel protocol drafts are silent about the = exact use of multiple values.

 

The potential deployment cases for multiple values are = (without making any assumption whether these cases are good/bad = deployment choices):

 

(1)Multiple = gateways may be on path. For example, draft-ietf-dots-architecture = discusses recursive signaling and also cases where multiple DOTS = gateways are involved.

(2)Requests = from multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The current approach has the merit to not make any = assumption on the gateway behavior (e.g., (2)), but it leads to a = confusion. For example, a DOTS server does not know whether multiple = client-ids supplied in a messages refer to multiple DOTS clients or to a = DOTS client and a set of on-path gateways. The protocol documents need = to be updated to avoid such confusion. Two options are listed below: =

 

Option 1 (Avoid making any assumption on gateways/proper = semantic distinction between clients and on-path = gateways)

-    Restrict the usage of ‘client-identifier’ to = carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘gateway-identifier’ pointing to = G1

 

Option 2 (Describe what a gateway cannot = do)

-    Update the architecture document to indicate that requests = are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values = only and only if multiple gateways are on-path. The order of the values = is important because the first one will be the one pointing to the = source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘client-identifier’ pointing to G1 = (in addition to C)

 

We are seeking for feedback from the WG on which direction = to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_02EF_01D37817.29DAC360-- From nobody Mon Dec 18 08:03:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AFB12D7F2 for ; Mon, 18 Dec 2017 08:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_WSab23pfI3 for ; Mon, 18 Dec 2017 08:03:28 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BCF12D7EE for ; Mon, 18 Dec 2017 08:03:27 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id C4E551C07DA; Mon, 18 Dec 2017 17:03:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 921BB60064; Mon, 18 Dec 2017 17:03:25 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 17:03:25 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTETAkWEwxEDVu2BwKBObuRgoPN33nA= Date: Mon, 18 Dec 2017 16:03:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> In-Reply-To: <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09A387OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:03:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09A387OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 16:45 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, See inline [Jon3] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 15:14 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 15:51 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, See inline [Jon2]. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 14:27 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, Going in the right direction, but see comments inline [Jon1]. As a side comment, I always have to think twice what "DOTS gateway server-s= ide" actually means. It actually means the DOTS client component logic of = a DOTS gateway. There is no definition of terms in the signal channel draf= t, but the definition could perhaps be added to the dots requirements draft= . Others may also get confused about this. Perhaps "DOTS gateway server-f= acing-side" is clearer, even though much longer to type! [Med] We do have the following definition in the requirements I-D: Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. [Jon2] Yes - actually, this adds to the confusion in my mind. For a singul= ar DOTS gateway, it could have a client-facing-side that is in the DOTS cli= ent domain, and a server-facing side that is in a different DOTS server dom= ain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for th= e "client-facing side" of a gateway to belong to the client domain and its = "server-facing side" to belong to the server domain? [Jon3]The recursive gateway comes immediately to mind - when an ISP cannot = handle the current attack and wants to invoke someone else to handle it. O= therwise to me, a gateway to me is either an aggregation point of clients w= ithin a common domain or a border between two different domains. [Med] Given that recursive signalling is opaque to the origin DOTS client, = all involved gateways are IMHO at the server-side (from the perspective of = the source client). The only difference is that the intermediate dots gatew= ay (server) is managed by Provider 1 while the final server is managed by a= nother provider. [Jon2] Also, being picky, does "Client-side DOTS gateway" (type of DOTS gat= eway) actually mean the same as "DOTS gateway client-side" (component withi= n a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - "xxx-side DOTS gateway" means this is owned and operated by xxx. - "DOTS gateway client-side" refers to the client-facing interface of a = DTOS gateway. It applies for both client- and server-side getaways. [Jon3] I agree with your distinct definitions, but not the use of the defin= ition in the requirements I-D to cover the definition of "DOTS Gateway clie= nt-side" Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway are= separate (the server-facing component has no real knowledge of what is hap= pening on the client-facing side), it needs to be the client-facing-side of= the DOTS gateway that assigns the (unique) client-identifier which is then= passed over to the server-facing-side for onward transmission. [Med] You are right if we zoom on the internal implementation of a DOTS gat= eway. This part of the text focuses on the external behavior of the DOTS ga= teway. The text does not need to zoom in given that the second sentence abo= ve says; [Jon2] In terms of helping the implementers, the use of only DOTS server be= ing allowed to generate a 'client-identifier' as discussed later. If "serv= er-side" was removed as in :- "client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity ..." Removes a lot of confusion in my mind. [Med] The "server-side" is important because we don't want client-side GWs = to reveal the identity of internal dots clients. [Jon3] Why do we need to be restrictive to "Server-side DOTS gateways" here= ? [Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients ar= e deployed in the client's domain. We do have this text (that may be tweaked): In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. [Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client= -identifiers" (which are obfuscated to hide identity). If they do not pass= on "client-identifiers" then the DOTS server they connect to (which is in = the same domain by definition) will not be able to differentiate between th= e different clients - the whole purpose of "client-identifiers" - or am I m= issing something here? [Med] For client-side DOTS gateways, the server does not need to rely upon = the identity of internal DOTS clients; the identity of the gw is sufficient= . Imagine an enterprise network with multiple DOTS clients and a DOTS gatew= ay located on the CPE that intercepts all messages from these clients. The = ultimate DOTS server does not to know about those DOTS clients. [Jon3] To me, the only time that "client-identifiers" may need to be droppe= d (not that I recommend doing this) is when a DOTS Gateway is sitting in bo= th a client's domain and a different server's domain as a domain border gat= eway. "to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. " DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer "a list of 'client-identifier' values; each value is pointi= ng to a unique DOTS client that is in the aggregated list. It is out of...." [Med] Deal. aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the client= component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS se= rver? There is nothing that I have spotted for this in the DOTS signal pro= tocol. [Med] I confirm, there is no such text in the draft. A deployment would con= sist in explicitly configuring a list of gateways (ACLs) on the server; the= server will trust client-id if and only if it is coming from a server-side= gateways in that list. [Jon2] Then do we need to instruct the implementers of the signal channel t= hat this is what should be done? [Med] What about adding this text: NEW: DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifi= ers'. If only the DOTS gateway server component (client-facing-side) is all= owed to generate the client-identifier (for possible onward forwarding), th= is gets around this issue as it is only the DOTS server component who is al= lowed to do the generation. [Jon1] In my implementation the DOTS server (gateway or not) always generat= es a client-identifier (will be changed if there already is a unique identi= fier following this discussion) which is associated with a mitigation-id et= c. so that the DOTS server can differentiate between the same mitigation-id= from different clients. [Med] Ok, thanks. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09A387OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see in= line.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 16:45
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuk= a
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

See inl= ine [Jon3]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 15:14
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 15:51
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

See inl= ine [Jon2].

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 14:27
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

Going i= n the right direction, but see comments inline [Jon1].

&n= bsp;

As a si= de comment, I always have to think twice what “DOTS gateway server-si= de” actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definiti= on of terms in the signal channel draft, but the definition could perhaps b= e added to the dots requirements draft.  Others may also get confused = about this.  Perhaps “DOTS gateway server-facing-side” is clearer, even though much longer to type!

 

[Med] We do h= ave the following definition in the requirements I-D:

 

&= nbsp;     Client-side DOTS gateways

&= nbsp;     are DOTS gateways that are in the DOTS client= 's domain, while

&= nbsp;     server-side DOTS gateways denote DOTS gateway= s that are in the

&= nbsp;     DOTS server's domain.=

&n= bsp;

&n= bsp;

[Jon2] = Yes – actually, this adds to the confusion in my mind.  For a si= ngular DOTS gateway, it could have a client-facing-side that is in the DOTS= client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one= or the other, but not both.

[Med] Do you = have a particular case in mind in which we should allow for the “clie= nt-facing side” of a gateway to belong to the client domain and its “server-facing side” to belong to the server domain? =

[Jon3]T= he recursive gateway comes immediately to mind – when an ISP cannot h= andle the current attack and wants to invoke someone else to handle it.&nbs= p; Otherwise to me, a gateway to me is either an aggregation point of clients within a common domain or a border between tw= o different domains.

[Med] Given t= hat recursive signalling is opaque to the origin DOTS client, all involved = gateways are IMHO at the server-side (from the perspective of the source client). The only difference is that the intermediate dots g= ateway (server) is managed by Provider 1 while the final server is managed = by another provider.

&n= bsp;

[Jon2] = Also, being picky, does “Client-side DOTS gateway” (type of DOT= S gateway) actually mean the same as “DOTS gateway client-side”= (component within a DOTS gateway)?

[Med] No. Tho= se are two distinct things/dimensions:

-    ̶= 0;xxx-side DOTS gateway” means this is owned and operated by xxx.

-    ̶= 0;DOTS gateway client-side” refers to the client-facing interface of = a DTOS gateway. It applies for both client- and server-side getaways.  

[Jon3] = I agree with your distinct definitions, but not the use of the definition i= n the requirements I-D to cover the definition of “DOTS Gateway clien= t-side”

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 13:04
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Jon,

 

Please see be= low two proposed changes to hopefully conclude on the issues discussed in t= his thread:

 

1st change:

 

OLD:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by the DOTS

&= nbsp;     gateway to propagate the DOTS client identity= from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server.  This al= lows the DOTS server to

&= nbsp;     accept mitigation requests with scopes which = the DOTS client is

&= nbsp;    authorized to manage.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;     in a manner that ensures that there is zero p= robability that the

&= nbsp;     same value will be assigned to a different DO= TS client.  The DOTS

&= nbsp;     gateway MUST conceal potentially sensitive DO= TS client identity

&= nbsp;     information.  The client-identifier attr= ibute SHOULD NOT be

&= nbsp;     generated and included by the DOTS client.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

NEW:

&= nbsp;  client-identifier:  The client identifier MAY be conveyed = by a

&= nbsp;     server-side DOTS gateway to propagate the DOT= S client identity

&= nbsp;     from the gateway's client-side to the gateway= 's server-side, and

&= nbsp;     from the gateway's server-side to the DOTS se= rver. 'client-

&= nbsp;     identifier' MAY be used by the final DOTS ser= ver for policy

&= nbsp;     enforcement purposes.

<= o:p> 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the server-side

[Jon1]  Actually, as the client and server components= of a DOTs gateway are separate (the server-facing component has no real kn= owledge of what is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assi= gns the (unique) client-identifier which is then passed over to the server-= facing-side for onward transmission.

 

[Med] You are right if we zoom on the internal implementation of= a DOTS gateway. This part of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that= the second sentence above says;

 

[Jon2] In terms of helping the implementers, the use of on= ly DOTS server being allowed to generate a ‘client-identifier’ = as discussed later.  If “server-side” was removed as in :-

“client-identifier:&nbs= p; The client identifier MAY be conveyed by a

      DOTS gateway to propagate t= he DOTS client identity …”

Removes a lot of confusion in my mind.

 

[Med] The “server-side” is important because we don&= #8217;t want client-side GWs to reveal the identity of internal dots client= s.

[Jon3] Why do we need to be restrictive to “Server-s= ide DOTS gateways” here?

[Med] For privacy concerns: e.g., avoid revealing how/where DOTS= clients are deployed in the client’s domain.

 

We do have this text (that may be tweaked):

 

&= nbsp;  In order to prevent leaking internal information outside a clie= nt-

&= nbsp;  domain, DOTS gateways located in the client-domain SHOULD NOT r= eveal

&= nbsp;  the identification information that pertains to internal DOTS c= lients

&= nbsp;  (client-identifier) unless explicitly configured to do so.=

<= o:p> 

 

[Jon3] “Client-side DOTS gateways” may, or may= not, want to pass on “client-identifiers” (which are obfuscate= d to hide identity).  If they do not pass on “client-identifiers= ” then the DOTS server they connect to (which is in the same domain by defin= ition) will not be able to differentiate between the different clients R= 11; the whole purpose of “client-identifiers” – or am I m= issing something here?

[Med] For client-side DOTS gateways, the server does not need to= rely upon the identity of internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS = clients and a DOTS gateway located on the CPE that intercepts all messages = from these clients. The ultimate DOTS server does not to know about those D= OTS clients.

 

[Jon3] To me, the only time that “client-identifiers= ” may need to be dropped (not that I recommend doing this) is when a = DOTS Gateway is sitting in both a client’s domain and a different server’s domain as a domain border gateway.

 

“to propagate the DOTS client identity from the gateway's

&= nbsp;     client-side to the gateway's server-side, and= from the gateway's

&= nbsp;     server-side to the DOTS server. ”

 

&= nbsp;     DOTS gateway in a manner that ensures that th= ere is zero

&= nbsp;     probability that the same value will be assig= ned to a different

&= nbsp;     DOTS client.  The server-side DOTS gatew= ay MUST conceal

&= nbsp;     potentially sensitive DOTS client identity in= formation.

<= o:p> 

&= nbsp;     If aggregating DOTS mitigation requests recei= ved from multiple

&= nbsp;     DOTS clients is enabled, the server-side DOTS= gateway has to include

&= nbsp;     a list of 'client-identifier' values; each va= lue is pointing to a

&= nbsp;     DOTS client.  It is out of scope of this= document to specify how

[Jon1] I prefer “a list of 'client-identifier' value= s; each value is pointing to a unique

      DOTS client that is in the = aggregated list.  It is out of….”

 

[Med] Deal.  

 

&= nbsp;     aggregation is implemented by a DOTS gateway.=

<= o:p> 

&= nbsp;     The client-identifier attribute MUST NOT be g= enerated and included

&= nbsp;     by DOTS clients.

<= o:p> 

&= nbsp;     DOTS servers MUST ignore client-identifier at= tributes that are

&= nbsp;     directly supplied by source DOTS clients.&nbs= p; This implies that first

&= nbsp;     server-side DOTS gateways MUST strip client-i= dentifier attributes

&= nbsp;     supplied by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS clie= nt and the client component of a DOTS gateway (i.e. server-facing-side) as = seen by a DOTS server?  There is nothing that I have spotted for this in the DOTS signal protocol.

 

[Med] I confirm, there is no such text in the draft. A deploymen= t would consist in explicitly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is= coming from a server-side gateways in that list.

 

[Jon2] Then do we need to instruct the implementers of the= signal channel that this is what should be done?

[Med] What about adding this text:

 

NEW:

&= nbsp;     DOTS servers MAY support a

&= nbsp;     configuration parameter (e.g., ACLs) to ident= ify DOTS gateways

&= nbsp;     that are trusted to supply client-identifier = attributes.

 

 

[Jon1] I do agree that true DOTS clients MUST NOT generate= ‘client-identifiers’. If only the DOTS gateway server componen= t (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this = issue as it is only the DOTS server component who is allowed to do the gene= ration.

 

[Jon1] In my implementation the DOTS server (gateway or no= t) always generates a client-identifier (will be changed if there already i= s a unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can = differentiate between the same mitigation-id from different clients.

[Med] Ok, thanks.

<= o:p> 

&= nbsp;     This is an optional attribute.

 

2nd change: Delete this text because client-identifier is uniquely assigned b= y the first server-side gateway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

&= nbsp;  If the 'client-identifier' value is already present in the=

&= nbsp;  mitigation request received from the DOTS client, the DOTS gate= way

&= nbsp;  MAY compute the 'client-identifier' value, as discussed above, = and

&= nbsp;  add the computed 'client-identifier' value to the end of the 'c= lient-

&= nbsp;  identifier' list.

[Jon1] OK

 

Comments and = modifications are more welcome.

 

Cheers,<= /o:p>

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.o= rg; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see in= line.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …= but broken clients may communicate directly with servers without any gatewa= y on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actuall= y,

=B7    &n= bsp;    (R1) = we do need MUST so that as a general rule clients do not insert a client-id= parameter in their requests.

=B7    &n= bsp;    And (= R2) DOTS servers MUST ignore client-ids that are supplied by the origin DOT= S clients.

 

In deployment= s without gateways, client-ids supplied by broken DOTS clients will be igno= red by the server as per R2.

In deployment= s with gateways, the first server-side gateway will follow R2 and strip any= value supplied by the client.

 

If we add tex= t to cover (R2), I don’t think we need a sentence about updating the = content because client-id is a value that is ***assigned*** exclusively by a dots gateway:

 

&= nbsp;     The 'client-identifier' value MUST be assigne= d by the DOTS gateway

&= nbsp;           &nbs= p;            &= nbsp;          ^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^  

&= nbsp;     in a manner that ensures that there is z= ero probability that the

&= nbsp;     same value will be assigned to a different DO= TS client. 

 =

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for= sharing your thoughts.

 

Please see co= mments inline.

 

Cheers,<= /o:p>

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There a= re also some complications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client = (C1aj) ------------------------------------- (S1j) DOTS gateway J (C2j) ---= -------\  

DOTS client = (C1bj) ----------------------------------------/    &nb= sp;            =              &n= bsp;   |

  =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |

DOTS client = (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) ---= ----- (S3)   

DOTS client = (C1bx) --------/          = ;            &n= bsp;        |   &nbs= p;            &= nbsp;            &nb= sp; 

  =             &nb= sp;            =             &nb= sp;            =        |     &n= bsp;            = ;             &= nbsp; 

DOTS client = (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/    &nb= sp;            =              &n= bsp;  

DOTS client = (C1by) --------/          = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This as= sumes that the DOTS forwarding path will always be the same (that is, the s= ame set of gateways will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree f= or the first server-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this = design in a multi-homing scenario with the same mitigation provider: the same req= uest from a multi-homed DOTS client will be presented to the server as bein= g distinct requests…while this is not. It may be the same request tha= t is forked among existent network attachments or a request that is sent over a first link, but a subsequent one over ano= ther link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’= ;m referring to this “[alias-name=3DServer1&client-identifer=3DCI= (C1ax),CI(C2x),CI(C3k)]”.=

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, t= hese are deployment-specific. My concern is to avoid design choices that ma= ke hidden assumptions.  

 

 

[Med] Separating both client-id fro= m gateway-id does not suffer from this issue (even when no aggregation). &n= bsp;  

 =

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we a= gree that one (unique) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess= you meant “restrict the number of aggregated clients per DOTS gatewa= y”, not the “number of DOTS clients serviced by a DOTS gateway&= #8221;. I would say this is deployment-specific. A deployment that enables signal/= data channel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please = note that I used “good/bad deployme= nt choices” in the initial message. Merging the requests will induce some complexity a= t the gateway, sure. From a protocol standpoint, I’m trying to be neu= tral on this. My main concern is to avoid making choices in the protocol th= at will have deployment implications.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 <= /p>

To avoid potential confli= cts and also in order to help the server select the appropriate policy to e= nforce, signal/data channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter t= o carry multiple values.

 <= /p>

Putting aside the extensi= bility argument of the data model, the signal/data channel protocol drafts = are silent about the exact use of multiple values.

 <= /p>

The potential deployment = cases for multiple values are (without making any assumption whether these = cases are good/bad deployment choices):

 <= /p>

(1)Multipl= e gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Request= s from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 <= /p>

The current approach has = the merit to not make any assumption on the gateway behavior (e.g., (2)), b= ut it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multi= ple DOTS clients or to a DOTS client and a set of on-path gateways. The pro= tocol documents need to be updated to avoid such confusion. Two options are= listed below:

 <= /p>

Option 1 (Avoid making an= y assumption on gateways/proper semantic distinction between clients and on= -path gateways)

- = ;   Restrict the usag= e of ‘client-identifier’ to carry identifiers of clients, not g= ateways.

- = ;   On-path gateways = may include a new parameter called ‘gateway-identifier’ to ease= contexts retrieval and avoid potential collisions.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘gateway-identifier’ pointing to G1

 <= /p>

Option 2 (Describe what a= gateway cannot do)

-  &n= bsp; Update the archit= ecture document to indicate that requests are not aggregated by a dots gate= way.

-  &n= bsp; ‘client-ide= ntifier’ includes multiple values only and only if multiple gateways = are on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients.

 <= /p>

An example is provided be= low:

 <= /p>

C=3D=3D=3D=3D=3DG1=3D=3D= =3D=3DG2=3D=3D=3D=3DS

 <= /p>

G1 will update the reques= t with ‘client-identifier’ pointing to C

G2 will update the reques= t with ‘client-identifier’ pointing to G1 (in addition to C)

 <= /p>

We are seeking for feedba= ck from the WG on which direction to take.

 <= /p>

Thoughts?

 <= /p>

Cheers,=

Med

 <= /p>

 <= /p>

 

--_000_787AE7BB302AE849A7480A190F8B93300A09A387OPEXCLILMA3corp_-- From nobody Mon Dec 18 08:29:20 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED89127735 for ; Mon, 18 Dec 2017 08:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9klpCsNvOAi for ; Mon, 18 Dec 2017 08:29:14 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB6D124C27 for ; Mon, 18 Dec 2017 08:29:13 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eQyHu-0004OW-Dl; Mon, 18 Dec 2017 16:29:10 +0000 From: "Jon Shallow" To: , , "kaname nishizuka" References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 18 Dec 2017 16:29:11 -0000 Message-ID: <031001d3781d$55f34f70$01d9ee50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0311_01D3781D.55FA7B60" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nANCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTETAkWEwxEDVu2BwAILYvd7Ajb4MCSgLGd+oA== Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:29:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0311_01D3781D.55FA7B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon4]. I have deleted some of the =93see inline = messages=94. =20 Regards =20 Jon =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med, =20 Going in the right direction, but see comments inline [Jon1]. =20 As a side comment, I always have to think twice what =93DOTS gateway server-side=94 actually means. It actually means the DOTS client = component logic of a DOTS gateway. There is no definition of terms in the signal channel draft, but the definition could perhaps be added to the dots requirements draft. Others may also get confused about this. Perhaps = =93DOTS gateway server-facing-side=94 is clearer, even though much longer to = type! =20 [Med] We do have the following definition in the requirements I-D:=20 =20 Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. =20 =20 [Jon2] Yes =96 actually, this adds to the confusion in my mind. For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for = the =93client-facing side=94 of a gateway to belong to the client domain and = its =93server-facing side=94 to belong to the server domain?=20 [Jon3]The recursive gateway comes immediately to mind =96 when an ISP = cannot handle the current attack and wants to invoke someone else to handle it. Otherwise to me, a gateway to me is either an aggregation point of = clients within a common domain or a border between two different domains. [Med] Given that recursive signalling is opaque to the origin DOTS = client, all involved gateways are IMHO at the server-side (from the perspective = of the source client). The only difference is that the intermediate dots gateway (server) is managed by Provider 1 while the final server is = managed by another provider. [Jon4] Hmm =96 I am not convinced. Some of your examples below actually = give examples for a DOTS gateway sitting in both client and (different) = server domains. =20 [Jon2] Also, being picky, does =93Client-side DOTS gateway=94 (type of = DOTS gateway) actually mean the same as =93DOTS gateway client-side=94 = (component within a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - =93xxx-side DOTS gateway=94 means this is owned and operated by = xxx. - =93DOTS gateway client-side=94 refers to the client-facing = interface of a DTOS gateway. It applies for both client- and server-side getaways. =20 [Jon3] I agree with your distinct definitions, but not the use of the definition in the requirements I-D to cover the definition of =93DOTS = Gateway client-side=94 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Jon,=20 =20 Please see below two proposed changes to hopefully conclude on the = issues discussed in this thread: =20 1st change:=20 =20 OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. =20 The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. =20 This is an optional attribute. =20 NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. =20 The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway = are separate (the server-facing component has no real knowledge of what is happening on the client-facing side), it needs to be the = client-facing-side of the DOTS gateway that assigns the (unique) client-identifier which is then passed over to the server-facing-side for onward transmission. =20 [Med] You are right if we zoom on the internal implementation of a DOTS gateway. This part of the text focuses on the external behavior of the = DOTS gateway. The text does not need to zoom in given that the second = sentence above says;=20 =20 [Jon2] In terms of helping the implementers, the use of only DOTS server being allowed to generate a =91client-identifier=92 as discussed later. = If =93server-side=94 was removed as in :- =93client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity =85=94 Removes a lot of confusion in my mind. =20 [Med] The =93server-side=94 is important because we don=92t want = client-side GWs to reveal the identity of internal dots clients.=20 [Jon3] Why do we need to be restrictive to =93Server-side DOTS = gateways=94 here? [Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients = are deployed in the client=92s domain. [Jon4] But all this (deployment etc.) information is in the client = domain only using your definition of a client-side DOTS gateway =96 so within = the client space who the really cares? [Jon4] But this information going into another domain is the security concern. However, to get a mitigation request to go between domains, = there has to be a border at some point. How do we handle that? What does the border look like (it cannot be a client-side or server-side DOTS gateway = as that is not allowed to straddle domains as you assert)?=20 =20 =20 We do have this text (that may be tweaked):=20 =20 In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. [Jon4] I had always read this as being a DOTS gateway on the border of a different client and server domain =20 [Jon3] =93Client-side DOTS gateways=94 may, or may not, want to pass on =93client-identifiers=94 (which are obfuscated to hide identity). If = they do not pass on =93client-identifiers=94 then the DOTS server they connect = to (which is in the same domain by definition) will not be able to differentiate between the different clients =96 the whole purpose of = =93client-identifiers=94 =96 or am I missing something here? [Med] For client-side DOTS gateways, the server does not need to rely = upon the identity of internal DOTS clients; the identity of the gw is = sufficient. Imagine an enterprise network with multiple DOTS clients and a DOTS = gateway located on the CPE that intercepts all messages from these clients. The ultimate DOTS server does not to know about those DOTS clients. [Jon4] Again an example of a DOTS gateway that sits both in a client and (different) server domain. =20 [Jon3] To me, the only time that =93client-identifiers=94 may need to be = dropped (not that I recommend doing this) is when a DOTS Gateway is sitting in = both a client=92s domain and a different server=92s domain as a domain border gateway. =20 =93to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. =94 =20 DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. =20 If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to = include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer =93a list of 'client-identifier' values; each value is pointing to a unique DOTS client that is in the aggregated list. It is out of=85.=94 =20 [Med] Deal. =20 =20 aggregation is implemented by a DOTS gateway. =20 The client-identifier attribute MUST NOT be generated and included by DOTS clients. =20 DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the = client component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server? There is nothing that I have spotted for this in the DOTS = signal protocol. =20 [Med] I confirm, there is no such text in the draft. A deployment would consist in explicitly configuring a list of gateways (ACLs) on the = server; the server will trust client-id if and only if it is coming from a server-side gateways in that list. =20 [Jon2] Then do we need to instruct the implementers of the signal = channel that this is what should be done? [Med] What about adding this text:=20 =20 NEW:=20 DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon4] I do not think ACL is the right term here. In the same way the a DOTS server needs to know the valid client IDs of the DOTS clients that = can use it (along with the valid target IP addresses etc.) =93valid = gateway=94 could be added in. I would just drop =93(e.g. ACLS)=94. =20 [Jon1] I do agree that true DOTS clients MUST NOT generate =91client-identifiers=92. If only the DOTS gateway server component (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is only = the DOTS server component who is allowed to do the generation. =20 [Jon1] In my implementation the DOTS server (gateway or not) always generates a client-identifier (will be changed if there already is a = unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differentiate between the same mitigation-id from different clients. [Med] Ok, thanks. =20 This is an optional attribute. =20 2nd change: Delete this text because client-identifier is uniquely = assigned by the first server-side gateway; there is no need to prepend = identifiers computed by other gateways.=20 =20 OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK=20 =20 Comments and modifications are more welcome.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med / Kaname, =20 =93I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client.=94 We do need to handle the case of a broken client (how does the DOTS = server know it is a DOTS gateway client or a real DOTS client?) who does not = obey the MUST. [Med] =85but broken clients may communicate directly with servers = without any gateway on the path.=20 =20 =93The client-identifier attribute SHOULD NOT be generated and included = by the DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.=94 =20 Is the safer option for me. =20 [Med] Actually,=20 =B7 (R1) we do need MUST so that as a general rule clients do = not insert a client-id parameter in their requests.=20 =B7 And (R2) DOTS servers MUST ignore client-ids that are = supplied by the origin DOTS clients.=20 =20 In deployments without gateways, client-ids supplied by broken DOTS = clients will be ignored by the server as per R2.=20 In deployments with gateways, the first server-side gateway will follow = R2 and strip any value supplied by the client.=20 =20 If we add text to cover (R2), I don=92t think we need a sentence about updating the content because client-id is a value that is ***assigned*** exclusively by a dots gateway: =20 The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = =20 in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. =20 =20 Otherwise, see [Jon] inline (8 times). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Thank you for sharing your thoughts.=20 =20 Please see comments inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med and all, =20 I think that =91gateway-identifier=92 is likely to cause more confusion = and will not actually help to try and solve what I perceive is the underlying = issue that has triggered this discussion - =93How do we handle = =91client-identifiers=92 when a DOTS gateway does aggregation?=94 [Med] There are also some complications even when no aggregation is in = use. See below.=20 =20 . I am leaning towards your Option 2. Some of my reasoning is below. =20 Background to client-identifiers. =20 In the general case (e.g. no DOTS gateway aggregation of filters / = aliases etc.), every time a request or update (both signal and data) passes = upstream through a DOTS gateway, an additional =91client-identifier=92 is added = to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, = say, an (possibly non unique alias-name) alias definition sent over the data = channel with a (possibly non unique mitigation-id) mitigation request using the = same alias-name sent over the signal channel. =20 Client Identification Usage Example =20 DOTS client (C1aj) ------------------------------------- (S1j) DOTS = gateway J (C2j) ----------\ =20 DOTS client (C1bj) ----------------------------------------/ | =20 | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS = gateway K (C3k) -------- (S3) =20 DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ =20 Where CI is =91client-identifier=92 =96 a unique hash of the client = identification :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)] =20 [Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client). =20 [Jon] The current text states =93If the 'client-identifier' value is = already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list.=94 =20 [Jon] The MAY is not a MUST for the simple reason that if the original = DOTS client client-identifier is computed correctly, it should be unique all = the way through the different DOTS gateways (so no additional = client-identifiers need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C1ax)]. The DOTS gateways = in the path can then change over time with no issues. =20 [Jon] All that is required then is that a DOTS gateway makes sure that = any Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional client-identifiers = (but still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway.=20 =20 [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier = =96 even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information. =20 [Med]I do see some implications of this design in a multi-homing = scenario with the same mitigation provider: the same request from a multi-homed = DOTS client will be presented to the server as being distinct = requests=85while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a = subsequent one over another link. =20 [Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) = in which case the client-identifier (which is not IP based) would be the = same over the different network interfaces. =20 [Med] I=92m referring to this =93[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]=94.= =20 [Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, = and hence different client-identifiers propagating up to the DOTS servers = =96 but as these are different provider domains will they ever join up into a = common domain? If they do, then this is where you could be getting conflicting requests =96 subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design choices that make hidden assumptions. =20 =20 =20 [Med] Separating both client-id from gateway-id does not suffer from = this issue (even when no aggregation). =20 =20 [Jon] Yes =96 the assumption being that all the client-identifiers are = unique =96 In which case I argue again that additional information =96 e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I=92m = fine.=20 =20 so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different CI(). =20 Then when C1ax requests a mitigation with alias-name=3DServer1, by the = time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]. =20 If C1aj also requests a mitigation with alias-name=3DServer1, S3 will = see the alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] = and match accordingly. =20 As responses come back from S3 to the originating client, the = appropriate CI(cxxx) gets stripped off so the originating client sees no =91client-identifier=92 fields at all. =20 This general solution is simple with only one disadvantage =96 there is = a limit of 20 - 24 client-identifiers (20 =96 24 DOTS gateways) that will = fit into a single UDP packet due to MTU restrictions. However in practice = there are unlikely to be this number of DOTS gateways. The count varies based = on how much other information needs to be put into the packet. =20 DOTS Gateway Session aggregation =20 There is no reason as to why multiple DOTS clients=92 signal and data = requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection =96 especially as different client-identifiers = separate out the different requests / responses. =20 This session aggregation is not the same as signal / data aggregation =20 NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation =20 [Med] Agree.=20 =20 DOTS Gateway signal / data aggregation challenges =20 Individual clients in general will generate their unique mitigation = requests =96 but may have common information (e.g. same protocol, ports, = alias-name). If the mitigation requests are not unique then we have potential = conflicts =96 not part of this discussion. =20 Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes =96 aggregating different port requirements = for different target-prefixes gets more interesting=85.. This adds in a lot = of potential complexity with potential for boundary condition error issues. =20 Aggregation of Filters is at first sight relatively simple - but there = then may be ordering challenges / conflicts =96 e.g. one filter has an IP = that is a white-list, and another has the same IP as a black-list =96 both valid = in the respective client environment. Ordering of conflicting filter = information is important and I am not sure that a DOTS gateway will do this = properly unless it either has some hints or complex rules to work with =96 just = adding in complexity where more things can potentially go wrong. =20 Use of gateway-identifier and client-identifier combination can be used = to partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 =96 24 *-identifiers in total due to packet MTU. Even if = we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 =96 20. Do we = really want to restrict the number of supported DOTS clients per DOTS gateway = if aggregation is supported? =20 [Med] I guess you meant =93restrict the number of aggregated clients per = DOTS gateway=94, not the =93number of DOTS clients serviced by a DOTS = gateway=94. I would say this is deployment-specific. A deployment that enables = signal/data channel aggregation is aware of this limitation.=20 =20 [Jon] Yes, that is better phrasing. [Med] OK.=20 =20 I still struggle with how do you actually do the aggregation (merging = of data/signal) at any gateway other than in a couple of simple cases out = of the many different scenarios. [Med] Please note that I used =93good/bad deployment choices=94 in the = initial message. Merging the requests will induce some complexity at the = gateway, sure. From a protocol standpoint, I=92m trying to be neutral on this. My = main concern is to avoid making choices in the protocol that will have = deployment implications. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi all,=20 =20 To avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called =93client-identifier=94. The design allows this = parameter to carry multiple values.=20 =20 Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of multiple = values.=20 =20 The potential deployment cases for multiple values are (without making = any assumption whether these cases are good/bad deployment choices): =20 (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also = cases where multiple DOTS gateways are involved.=20 (2)Requests from multiple clients may be aggregated by the same = server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. =20 =20 The current approach has the merit to not make any assumption on the = gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:=20 =20 Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers = of clients, not gateways.=20 - On-path gateways may include a new parameter called =91gateway-identifier=92 to ease contexts retrieval and avoid potential collisions. =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 =20 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if = multiple gateways are on-path. The order of the values is important because the = first one will be the one pointing to the source DOTS clients.=20 =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 = (in addition to C) =20 We are seeking for feedback from the WG on which direction to take.=20 =20 Thoughts? =20 Cheers, Med =20 =20 =20 ------=_NextPart_000_0311_01D3781D.55FA7B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline [Jon4].=A0 I = have deleted some of the “see inline = messages”.

 

Regards

 

Jon

 

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi = Med,

 

Going in the right = direction, but see comments inline [Jon1].

 

As a side comment, I = always have to think twice what “DOTS gateway server-side” = actually means.  It actually means the DOTS client component = logic of a DOTS gateway.  There is no definition of terms in the = signal channel draft, but the definition could perhaps be added to the = dots requirements draft.  Others may also get confused about = this.  Perhaps “DOTS gateway server-facing-side” is = clearer, even though much longer to type!

 

[Med] We do have the following definition in = the requirements I-D:

 

      = Client-side DOTS gateways

      are = DOTS gateways that are in the DOTS client's domain, = while

      = server-side DOTS gateways denote DOTS gateways that are in = the

      = DOTS server's = domain.

 

 

[Jon2] Yes – = actually, this adds to the confusion in my mind.  For a singular = DOTS gateway, it could have a client-facing-side that is in the DOTS = client domain, and a server-facing side that is in a different DOTS = server domain.  The quoted text implies it is one or the other, but = not both.

[Med] Do you have a particular case in mind in = which we should allow for the “client-facing side” of a = gateway to belong to the client domain and its “server-facing = side” to belong to the server domain?

[Jon3]The recursive = gateway comes immediately to mind – when an ISP cannot handle the = current attack and wants to invoke someone else to handle it.  = Otherwise to me, a gateway to me is either an aggregation point of = clients within a common domain or a border between two different = domains.

[Med] Given that recursive signalling is = opaque to the origin DOTS client, all involved gateways are IMHO at the = server-side (from the perspective of the source client). The only = difference is that the intermediate dots gateway (server) is managed by = Provider 1 while the final server is managed by another = provider.

[Jon4] Hmm – I am = not convinced.=A0 Some of your examples below actually give examples for = a DOTS gateway sitting in both client and (different) server = domains.

 

[Jon2] Also, being = picky, does “Client-side DOTS gateway” (type of DOTS = gateway) actually mean the same as “DOTS gateway = client-side” (component within a DOTS = gateway)?

[Med] No. Those are two distinct = things/dimensions:

-    = “xxx-side DOTS gateway” means this = is owned and operated by xxx.

-    = “DOTS gateway client-side” refers = to the client-facing interface of a DTOS gateway. It applies for both = client- and server-side getaways.  

[Jon3] I agree with your = distinct definitions, but not the use of the definition in the = requirements I-D to cover the definition of “DOTS Gateway = client-side”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 13:04
To: Jon Shallow; = dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Jon,

 

Please see below two proposed changes to = hopefully conclude on the issues discussed in this = thread:

 

1st change: =

 

OLD:

   = client-identifier:  The client identifier MAY be conveyed by the = DOTS

      = gateway to propagate the DOTS client identity from the = gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server.  This allows the DOTS server = to

      = accept mitigation requests with scopes which the DOTS client = is

     autho= rized to manage.

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      in = a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  The = DOTS

      = gateway MUST conceal potentially sensitive DOTS client = identity

      = information.  The client-identifier attribute SHOULD NOT = be

      = generated and included by the DOTS client.

 

      = This is an optional attribute.

 

NEW:

   = client-identifier:  The client identifier MAY be conveyed by = a

      = server-side DOTS gateway to propagate the DOTS client = identity

      = from the gateway's client-side to the gateway's server-side, = and

      = from the gateway's server-side to the DOTS server. = 'client-

      = identifier' MAY be used by the final DOTS server for = policy

      = enforcement purposes.

 

      The = 'client-identifier' value MUST be assigned by the = server-side

[Jon1]  Actually, = as the client and server components of a DOTs gateway are separate (the = server-facing component has no real knowledge of what is happening on = the client-facing side), it needs to be the client-facing-side of the = DOTS gateway that assigns the (unique) client-identifier which is then = passed over to the server-facing-side for onward = transmission.

 

[Med] You are right if = we zoom on the internal implementation of a DOTS gateway. This part of = the text focuses on the external behavior of the DOTS gateway. The text = does not need to zoom in given that the second sentence above says; =

 <= /p>

[Jon2] In terms of = helping the implementers, the use of only DOTS server being allowed to = generate a ‘client-identifier’ as discussed later.  If = “server-side” was removed as in :-

“client-identifier:=   The client identifier MAY be conveyed by = a

    &= nbsp; DOTS gateway to propagate the DOTS client identity = …”

Removes a = lot of confusion in my mind.

 

[Med] The = “server-side” is important because we don’t want = client-side GWs to reveal the identity of internal dots clients. =

[Jon3] Why do we need to = be restrictive to “Server-side DOTS gateways” = here?

[Med] For privacy = concerns: e.g., avoid revealing how/where DOTS clients are deployed in = the client’s domain.

[Jon4] But all this = (deployment etc.) information is in the client domain only using your = definition of a client-side DOTS gateway – so within the client = space who the really cares?

[Jon4] But this = information going into another domain is the security concern.=A0 = However, to get a mitigation request to go between domains, there has to = be a border at some point.=A0 How do we handle that?=A0 What does the = border look like (it cannot be a client-side or server-side DOTS gateway = as that is not allowed to straddle domains as you assert)? =

=A0

 

We do have this text = (that may be tweaked):

 

   In order to prevent = leaking internal information outside a client-

   domain, DOTS gateways = located in the client-domain SHOULD NOT reveal

   the identification = information that pertains to internal DOTS = clients

   (client-identifier) = unless explicitly configured to do so.

[Jon4] I had always read = this as being a DOTS gateway on the border of a different client and = server domain

 

[Jon3] = “Client-side DOTS gateways” may, or may not, want to pass on = “client-identifiers” (which are obfuscated to hide = identity).  If they do not pass on “client-identifiers” = then the DOTS server they connect to (which is in the same domain by = definition) will not be able to differentiate between the different = clients – the whole purpose of “client-identifiers” = – or am I missing something here?

[Med] For client-side = DOTS gateways, the server does not need to rely upon the identity of = internal DOTS clients; the identity of the gw is sufficient. Imagine an = enterprise network with multiple DOTS clients and a DOTS gateway located = on the CPE that intercepts all messages from these clients. The ultimate = DOTS server does not to know about those DOTS clients.

[Jon4] Again an example = of a DOTS gateway that sits both in a client and (different) server = domain.

=

 

[Jon3] To me, the only = time that “client-identifiers” may need to be dropped (not = that I recommend doing this) is when a DOTS Gateway is sitting in both a = client’s domain and a different server’s domain as a domain = border gateway.

<= p class=3DMsoNormal> 

“to propagate the DOTS client = identity from the gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server. ”

 

      = DOTS gateway in a manner that ensures that there is = zero

      = probability that the same value will be assigned to a = different

      = DOTS client.  The server-side DOTS gateway MUST = conceal

      = potentially sensitive DOTS client identity = information.

 

      If = aggregating DOTS mitigation requests received from = multiple

      = DOTS clients is enabled, the server-side DOTS gateway has to = include

      a = list of 'client-identifier' values; each value is pointing to = a

      = DOTS client.  It is out of scope of this document to specify = how

[Jon1] I prefer “a = list of 'client-identifier' values; each value is pointing to a = unique

    &= nbsp; DOTS client that is in the aggregated list.  It is out = of….”

 

[Med] Deal. =  

 

      = aggregation is implemented by a DOTS gateway.

 

      The = client-identifier attribute MUST NOT be generated and = included

      by = DOTS clients.

 

      = DOTS servers MUST ignore client-identifier attributes that = are

      = directly supplied by source DOTS clients.  This implies that = first

      = server-side DOTS gateways MUST strip client-identifier = attributes

      = supplied by DOTS clients.

[Jon1] How do we = differentiate between an actual DOTS client and the client component of = a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server?  = There is nothing that I have spotted for this in the DOTS signal = protocol.

 

[Med] I confirm, there = is no such text in the draft. A deployment would consist in explicitly = configuring a list of gateways (ACLs) on the server; the server will = trust client-id if and only if it is coming from a server-side gateways = in that list.

 <= /p>

[Jon2] Then do we need = to instruct the implementers of the signal channel that this is what = should be done?

[Med] What about = adding this text:

 

NEW: =

      = ;DOTS servers MAY support a

      = configuration parameter (e.g., ACLs) to identify DOTS = gateways

      = that are trusted to supply client-identifier = attributes.

[Jon4] I do not think = ACL is the right term here.=A0 In the same way the a DOTS server needs = to know the valid client IDs of the DOTS clients that can use it (along = with the valid target IP addresses etc.) “valid gateway” = could be added in.=A0 I would just drop “(e.g. = ACLS)”.

 

[Jon1] I do agree that = true DOTS clients MUST NOT generate ‘client-identifiers’. If = only the DOTS gateway server component (client-facing-side) is allowed = to generate the client-identifier (for possible onward forwarding), this = gets around this issue as it is only the DOTS server component who is = allowed to do the generation.

 <= /p>

[Jon1] In my = implementation the DOTS server (gateway or not) always generates a = client-identifier (will be changed if there already is a unique = identifier following this discussion) which is associated with a = mitigation-id etc. so that the DOTS server can differentiate between the = same mitigation-id from different clients.

[Med] Ok, = thanks.

 

      = This is an optional attribute.

 

2nd change: Delete this text = because client-identifier is uniquely assigned by the first server-side = gateway; there is no need to prepend identifiers computed by other = gateways.

 

OLD:

   If the = 'client-identifier' value is already present in = the

   mitigation request = received from the DOTS client, the DOTS gateway

   MAY compute the = 'client-identifier' value, as discussed above, = and

   add the computed = 'client-identifier' value to the end of the = 'client-

   identifier' = list.

[Jon1] OK =

 

Comments and modifications are more welcome. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de mohamed.boucadair@orange.com=
Envoy=E9 : lundi 18 d=E9cembre 2017 = 13:28
=C0 : Jon Shallow; dots@ietf.org; kaname = nishizuka
Objet : Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi Med / = Kaname,

 

“I = propose making it "MUST NOT":
The client-identifier attribute MUST NOT = be
      generated and included by the DOTS = client.”

We do need to handle the case of a broken client = (how does the DOTS server know it is a DOTS gateway client or a real = DOTS client?) who does not obey the MUST.

[Med] …but broken clients may = communicate directly with servers without any gateway on the path. =

 

“The = client-identifier attribute SHOULD NOT be generated and included by the = DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.”

 

Is the safer option for = me.

 

[Med] Actually,

=B7         = (R1) we do need MUST so that as a general rule = clients do not insert a client-id parameter in their requests. =

=B7         = And (R2) DOTS servers MUST ignore client-ids = that are supplied by the origin DOTS clients.

 

In deployments without gateways, client-ids = supplied by broken DOTS clients will be ignored by the server as per R2. =

In deployments with gateways, the first = server-side gateway will follow R2 and strip any value supplied by the = client.

 

If we add text to cover (R2), I don’t = think we need a sentence about updating the content because client-id is = a value that is ***assigned*** exclusively by a dots = gateway:

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      = ;            =             &= nbsp;     = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   =

      = ;in a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  =

 

Otherwise, see [Jon] inline (8 = times).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 06:59
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Jon,

 

Thank you for sharing your thoughts. =

 

Please see comments = inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : samedi 16 d=E9cembre 2017 = 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”

[Med] There are also some complications even = when no aggregation is in use. See below.

 

.  I am leaning = towards your Option 2.  Some of my reasoning is = below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

       &nb= sp;           &nbs= p;            = ;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS client (C1ax) ----- (S1x) DOTS gateway = X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)    =

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  |         &= nbsp;           &n= bsp;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway = Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOTS forwarding = path will always be the same (that is, the same set of gateways will be = solicited for requests coming from a given DOTS = client).

 

[Jon] The current text = states “If the 'client-identifier' value is already present in = the

   = mitigation request received from the DOTS client, the DOTS = gateway

   = MAY compute the 'client-identifier' value, as discussed above, = and

   = add the computed 'client-identifier' value to the end of the = 'client-

   identifier' = list.”

 

[Jon]  The MAY is = not a MUST for the simple reason that if the original DOTS client = client-identifier is computed correctly, it should be unique all the way = through the different DOTS gateways (so no additional client-identifiers = need to get added) so that S3 just sees = [alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS = gateways in the path can then change over time with no = issues.

 

[Jon] All that is = required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional = client-identifiers (but still adds in the first one if the first DOTS = gateway).

[Med] Agree for the first server-side gateway. =

 

[Jon] NOTE: A DOTS = gateway can elect to not add in any client-identifier – even if it = is the first in the chain if it wants to hide the client information, = but this will potentially cause information differentiation issues at = the DOTS server and I would not recommend it as client-identifiers, if = created properly, obfuscate the actual client information.

 

[Med]I do see some implications of this design in a = multi-homing scenario with the same mitigation provider: the same = request from a multi-homed DOTS client will be presented to the server = as being distinct requests…while this is not. It may be the same = request that is forked among existent network attachments or a request = that is sent over a first link, but a subsequent one over another = link.

 

[Jon] Perhaps I am = missing something here, but I would be expecting a multi-homed device to = be using the same PKI certificate (or equivalent) in which case the = client-identifier (which is not IP based) would be the same over the = different network interfaces. 

[Med] I’m referring to this = “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

 

[Jon] If however, the = different network interfaces are connected to different DOTS provider = domains, then there will be multiple PKI certs, and hence different = client-identifiers propagating up to the DOTS servers – but as = these are different provider domains will they ever join up into a = common domain?  If they do, then this is where you could be getting = conflicting requests – subject of another = discussion.

[Med] Sure, these are deployment-specific. My = concern is to avoid design choices that make hidden assumptions. =  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation). =    

 

[Jon] Yes – the = assumption being that all the client-identifiers are unique – In = which case I argue again that additional information – e.g. = gateway-identifiers are irrelevant (and also are useless when there are = multiple paths through the DOTS gateways as you refer to = above).

[Med] If we agree that one (unique) client-id = is supplied, then I’m fine.

 

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 = can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

[Med] Agree.

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

[Med] I guess you meant “restrict the = number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would = say this is deployment-specific. A deployment that enables signal/data = channel aggregation is aware of this limitation. =

 

[Jon] Yes, that is = better phrasing.

[Med] OK.

 

  I still struggle = with how do you actually do the aggregation (merging of data/signal) at = any gateway other than in a couple of simple cases out of the many = different scenarios.

[Med] Please note that I used = “good/bad = deployment choices” in the initial message. Merging the = requests will induce some complexity at the gateway, sure. From a = protocol standpoint, I’m trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have = deployment implications.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the = server select the appropriate policy to enforce, signal/data channel = protocol drafts specify a parameter called = “client-identifier”. The design allows this parameter to = carry multiple values.

 

Putting aside the extensibility argument of the data = model, the signal/data channel protocol drafts are silent about the = exact use of multiple values.

 

The potential deployment cases for multiple values are = (without making any assumption whether these cases are good/bad = deployment choices):

 

(1)Multiple = gateways may be on path. For example, draft-ietf-dots-architecture = discusses recursive signaling and also cases where multiple DOTS = gateways are involved.

(2)Requests = from multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The current approach has the merit to not make any = assumption on the gateway behavior (e.g., (2)), but it leads to a = confusion. For example, a DOTS server does not know whether multiple = client-ids supplied in a messages refer to multiple DOTS clients or to a = DOTS client and a set of on-path gateways. The protocol documents need = to be updated to avoid such confusion. Two options are listed below: =

 

Option 1 (Avoid making any assumption on gateways/proper = semantic distinction between clients and on-path = gateways)

-    Restrict the usage of ‘client-identifier’ to = carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘gateway-identifier’ pointing to = G1

 

Option 2 (Describe what a gateway cannot = do)

-    Update the architecture document to indicate that requests = are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values = only and only if multiple gateways are on-path. The order of the values = is important because the first one will be the one pointing to the = source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘client-identifier’ pointing to G1 = (in addition to C)

 

We are seeking for feedback from the WG on which direction = to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_0311_01D3781D.55FA7B60-- From nobody Mon Dec 18 23:15:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4AB12DA07 for ; Mon, 18 Dec 2017 23:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2JSJPiIdZqk for ; Mon, 18 Dec 2017 23:15:19 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE2B124D68 for ; Mon, 18 Dec 2017 23:15:18 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7EFC2C0B55; Tue, 19 Dec 2017 08:15:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4F6ED12007D; Tue, 19 Dec 2017 08:15:17 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 08:15:17 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTETAkWEwxEDVu2BwKBObuRgoPN33nC+GQrrgP//BNyQ Date: Tue, 19 Dec 2017 07:15:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09A920@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <031001d3781d$55f34f70$01d9ee50$@jpshallow.com> In-Reply-To: <031001d3781d$55f34f70$01d9ee50$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09A920OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 07:15:24 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09A920OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 17:29 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, See inline [Jon4]. I have deleted some of the "see inline messages". Regards Jon De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, Going in the right direction, but see comments inline [Jon1]. As a side comment, I always have to think twice what "DOTS gateway server-s= ide" actually means. It actually means the DOTS client component logic of = a DOTS gateway. There is no definition of terms in the signal channel draf= t, but the definition could perhaps be added to the dots requirements draft= . Others may also get confused about this. Perhaps "DOTS gateway server-f= acing-side" is clearer, even though much longer to type! [Med] We do have the following definition in the requirements I-D: Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. [Jon2] Yes - actually, this adds to the confusion in my mind. For a singul= ar DOTS gateway, it could have a client-facing-side that is in the DOTS cli= ent domain, and a server-facing side that is in a different DOTS server dom= ain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for th= e "client-facing side" of a gateway to belong to the client domain and its = "server-facing side" to belong to the server domain? [Jon3]The recursive gateway comes immediately to mind - when an ISP cannot = handle the current attack and wants to invoke someone else to handle it. O= therwise to me, a gateway to me is either an aggregation point of clients w= ithin a common domain or a border between two different domains. [Med] Given that recursive signalling is opaque to the origin DOTS client, = all involved gateways are IMHO at the server-side (from the perspective of = the source client). The only difference is that the intermediate dots gatew= ay (server) is managed by Provider 1 while the final server is managed by a= nother provider. [Jon4] Hmm - I am not convinced. Some of your examples below actually give= examples for a DOTS gateway sitting in both client and (different) server = domains. [Med] I suspect the disconnect is caused by mixing connectivity and DOTS co= ntrol aspects. [Jon2] Also, being picky, does "Client-side DOTS gateway" (type of DOTS gat= eway) actually mean the same as "DOTS gateway client-side" (component withi= n a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - "xxx-side DOTS gateway" means this is owned and operated by xxx. - "DOTS gateway client-side" refers to the client-facing interface of a = DTOS gateway. It applies for both client- and server-side getaways. [Jon3] I agree with your distinct definitions, but not the use of the defin= ition in the requirements I-D to cover the definition of "DOTS Gateway clie= nt-side" Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway are= separate (the server-facing component has no real knowledge of what is hap= pening on the client-facing side), it needs to be the client-facing-side of= the DOTS gateway that assigns the (unique) client-identifier which is then= passed over to the server-facing-side for onward transmission. [Med] You are right if we zoom on the internal implementation of a DOTS gat= eway. This part of the text focuses on the external behavior of the DOTS ga= teway. The text does not need to zoom in given that the second sentence abo= ve says; [Jon2] In terms of helping the implementers, the use of only DOTS server be= ing allowed to generate a 'client-identifier' as discussed later. If "serv= er-side" was removed as in :- "client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity ..." Removes a lot of confusion in my mind. [Med] The "server-side" is important because we don't want client-side GWs = to reveal the identity of internal dots clients. [Jon3] Why do we need to be restrictive to "Server-side DOTS gateways" here= ? [Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients ar= e deployed in the client's domain. [Jon4] But all this (deployment etc.) information is in the client domain o= nly using your definition of a client-side DOTS gateway - so within the cli= ent space who the really cares? [Jon4] But this information going into another domain is the security conce= rn. However, to get a mitigation request to go between domains, there has = to be a border at some point. How do we handle that? What does the border= look like (it cannot be a client-side or server-side DOTS gateway as that = is not allowed to straddle domains as you assert)? [Med] It looks like what is described in the architecture draft: a gateway = located in the server-side. example.net domain . . . . . . . . . . . . . . . . . . Gn . +----+ 1 . +----+ +-----------+ . | Cc |<--------->| Sn |~~~~~~~| Mitigator | . +----+ . +=3D=3D=3D=3D+ | Mn | . . | Cn | +-----------+ . example.com . +----+ . client . ^ . . . .|. . . . . . . . . . . . . . | 1 | | . . .|. . . . . . . . . . . . . . . v . . +----+ +-----------+ . . | So |~~~~~~~| Mitigator | . . +----+ | Mo | . . +-----------+ . . . . . . . . . . . . . . . . . . . . example.org domain Figure 13: Recursive Signaling We do have this text (that may be tweaked): In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. [Jon4] I had always read this as being a DOTS gateway on the border of a di= fferent client and server domain [Med] The mention which is important in that text is: "DOTS gateways locate= d in the client-domain". [Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client= -identifiers" (which are obfuscated to hide identity). If they do not pass= on "client-identifiers" then the DOTS server they connect to (which is in = the same domain by definition) will not be able to differentiate between th= e different clients - the whole purpose of "client-identifiers" - or am I m= issing something here? [Med] For client-side DOTS gateways, the server does not need to rely upon = the identity of internal DOTS clients; the identity of the gw is sufficient= . Imagine an enterprise network with multiple DOTS clients and a DOTS gatew= ay located on the CPE that intercepts all messages from these clients. The = ultimate DOTS server does not to know about those DOTS clients. [Jon4] Again an example of a DOTS gateway that sits both in a client and (d= ifferent) server domain. [Med] The CPE is in the border from a connectivity standpoint, but for DOTS= , the gateway is under the control of the client. I don't see the "server d= omain" part in this example. [Jon3] To me, the only time that "client-identifiers" may need to be droppe= d (not that I recommend doing this) is when a DOTS Gateway is sitting in bo= th a client's domain and a different server's domain as a domain border gat= eway. "to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. " DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer "a list of 'client-identifier' values; each value is pointi= ng to a unique DOTS client that is in the aggregated list. It is out of...." [Med] Deal. aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the client= component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS se= rver? There is nothing that I have spotted for this in the DOTS signal pro= tocol. [Med] I confirm, there is no such text in the draft. A deployment would con= sist in explicitly configuring a list of gateways (ACLs) on the server; the= server will trust client-id if and only if it is coming from a server-side= gateways in that list. [Jon2] Then do we need to instruct the implementers of the signal channel t= hat this is what should be done? [Med] What about adding this text: NEW: DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon4] I do not think ACL is the right term here. In the same way the a DO= TS server needs to know the valid client IDs of the DOTS clients that can u= se it (along with the valid target IP addresses etc.) "valid gateway" could= be added in. I would just drop "(e.g. ACLS)". [Med] Dropped. [Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifi= ers'. If only the DOTS gateway server component (client-facing-side) is all= owed to generate the client-identifier (for possible onward forwarding), th= is gets around this issue as it is only the DOTS server component who is al= lowed to do the generation. [Jon1] In my implementation the DOTS server (gateway or not) always generat= es a client-identifier (will be changed if there already is a unique identi= fier following this discussion) which is associated with a mitigation-id et= c. so that the DOTS server can differentiate between the same mitigation-id= from different clients. [Med] Ok, thanks. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09A920OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 17:29
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuk= a
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

See inl= ine [Jon4].  I have deleted some of the “see inline messagesR= 21;.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

Going i= n the right direction, but see comments inline [Jon1].

&n= bsp;

As a si= de comment, I always have to think twice what “DOTS gateway server-si= de” actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definiti= on of terms in the signal channel draft, but the definition could perhaps b= e added to the dots requirements draft.  Others may also get confused = about this.  Perhaps “DOTS gateway server-facing-side” is clearer, even though much longer to type!

 

[Med] We do have the following = definition in the requirements I-D:

 

   &= nbsp;  Client-side DOTS gateways

   &= nbsp;  are DOTS gateways that are in the DOTS client's domain, while

   &= nbsp;  server-side DOTS gateways denote DOTS gateways that are in the<= o:p>

   &= nbsp;  DOTS server's domain.

&n= bsp;

&n= bsp;

[Jon2] = Yes – actually, this adds to the confusion in my mind.  For a si= ngular DOTS gateway, it could have a client-facing-side that is in the DOTS= client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one= or the other, but not both.

[Med] Do you have a particular = case in mind in which we should allow for the “client-facing sideR= 21; of a gateway to belong to the client domain and its “server-facin= g side” to belong to the server domain?

[Jon3]T= he recursive gateway comes immediately to mind – when an ISP cannot h= andle the current attack and wants to invoke someone else to handle it.&nbs= p; Otherwise to me, a gateway to me is either an aggregation point of clients within a common domain or a border between tw= o different domains.

[Med] Given that recursive sign= alling is opaque to the origin DOTS client, all involved gateways are IMHO = at the server-side (from the perspective of the source client). The only difference is that the intermediate dots gateway = (server) is managed by Provider 1 while the final server is managed by anot= her provider.

[Jon4] = Hmm – I am not convinced.  Some of your examples below actually = give examples for a DOTS gateway sitting in both client and (different) ser= ver domains.

[Med] I suspect the disconnect = is caused by mixing connectivity and DOTS control aspects.

&n= bsp;

[Jon2] = Also, being picky, does “Client-side DOTS gateway” (type of DOT= S gateway) actually mean the same as “DOTS gateway client-side”= (component within a DOTS gateway)?

[Med] No. Those are two distinc= t things/dimensions:

-  = ;  “xxx-side DOTS ga= teway” means this is owned and operated by xxx.

-  = ;  “DOTS gateway cli= ent-side” refers to the client-facing interface of a DTOS gateway. It= applies for both client- and server-side getaways.  

[Jon3] = I agree with your distinct definitions, but not the use of the definition i= n the requirements I-D to cover the definition of “DOTS Gateway clien= t-side”

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 13:04
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Jon,

 

Please see below two proposed c= hanges to hopefully conclude on the issues discussed in this thread:

 

1st change:

 

OLD:

   client= -identifier:  The client identifier MAY be conveyed by the DOTS

   &= nbsp;  gateway to propagate the DOTS client identity from the gateway'= s

   &= nbsp;  client-side to the gateway's server-side, and from the gateway'= s

   &= nbsp;  server-side to the DOTS server.  This allows the DOTS serv= er to

   &= nbsp;  accept mitigation requests with scopes which the DOTS client is=

   &= nbsp; authorized to manage.

 

   &= nbsp;  The 'client-identifier' value MUST be assigned by the DOTS gate= way

   &= nbsp;  in a manner that ensures that there is zero probability that th= e

   &= nbsp;  same value will be assigned to a different DOTS client.  T= he DOTS

   &= nbsp;  gateway MUST conceal potentially sensitive DOTS client identity=

   &= nbsp;  information.  The client-identifier attribute SHOULD NOT b= e

   &= nbsp;  generated and included by the DOTS client.

 

   &= nbsp;  This is an optional attribute.

 

NEW:

   client= -identifier:  The client identifier MAY be conveyed by a

   &= nbsp;  server-side DOTS gateway to propagate the DOTS client identity<= o:p>

   &= nbsp;  from the gateway's client-side to the gateway's server-side, an= d

   &= nbsp;  from the gateway's server-side to the DOTS server. 'client-

   &= nbsp;  identifier' MAY be used by the final DOTS server for policy

   &= nbsp;  enforcement purposes.

 

   &= nbsp;  The 'client-identifier' value MUST be assigned by the server-si= de

[Jon1]  Actually, as the client and server components= of a DOTs gateway are separate (the server-facing component has no real kn= owledge of what is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assi= gns the (unique) client-identifier which is then passed over to the server-= facing-side for onward transmission.

&n= bsp;

[Med] Y= ou are right if we zoom on the internal implementation of a DOTS gateway. T= his part of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that the seco= nd sentence above says;

 

[Jon2] In terms of helping the implementers, the use of on= ly DOTS server being allowed to generate a ‘client-identifier’ = as discussed later.  If “server-side” was removed as in :-

“client-identifier:&nbs= p; The client identifier MAY be conveyed by a

      DOTS gateway to propagate t= he DOTS client identity …”

Removes a lot of confusion in my mind.

&n= bsp;

[Med] T= he “server-side” is important because we don’t want clien= t-side GWs to reveal the identity of internal dots clients.

[Jon3] Why do we need to be restrictive to “Server-s= ide DOTS gateways” here?

[Med] F= or privacy concerns: e.g., avoid revealing how/where DOTS clients are deplo= yed in the client’s domain.

[Jon4] But all this (deployment etc.) information is in th= e client domain only using your definition of a client-side DOTS gateway &#= 8211; so within the client space who the really cares?

[Jon4] But this information going into another domain is t= he security concern.  However, to get a mitigation request to go betwe= en domains, there has to be a border at some point.  How do we handle that?  What does the border look like (= it cannot be a client-side or server-side DOTS gateway as that is not allow= ed to straddle domains as you assert)?

[Med] I= t looks like what is described in the architecture draft: a gateway located= in the server-side.

 <= o:p>

   &= nbsp;           &nbs= p;        example.net domain<= /span>

   &= nbsp;           &nbs= p;        . . . . . . . . . . . . . . . = . .

   &= nbsp;           &nbs= p;        .    Gn &n= bsp;            = ;           .<= /span>

   &= nbsp;      +----+    1 = ;  .  +----+       +---= --------+   .

   &= nbsp;      | Cc |<--------->| Sn |~~~~~~~| M= itigator |   .

   &= nbsp;      +----+    &= nbsp;   .  +=3D=3D=3D=3D+    &nb= sp;  |     Mn    |   .

   &= nbsp;           &nbs= p;        .  | Cn |  &nbs= p;    +-----------+   .<= /p>

   &= nbsp;    example.com     .  +--= --+           &n= bsp;           .

   &= nbsp;       client    &nb= sp;  .    ^       &n= bsp;            &nbs= p;     .

   &= nbsp;           &nbs= p;        . . .|. . . . . . . . . . . . = . .

   &= nbsp;           &nbs= p;             = |

   &= nbsp;           &nbs= p;           1 |

   &= nbsp;           &nbs= p;             = |

   &= nbsp;           &nbs= p;        . . .|. . . . . . . . . . . . = . .

   &= nbsp;           &nbs= p;        .    v &nb= sp;            =             .

   &= nbsp;           &nbs= p;        .  +----+ &n= bsp;     +-----------+   .=

   &= nbsp;           &nbs= p;        .  | So |~~~~~~~| Mitigat= or |   .

   &= nbsp;           &nbs= p;        .  +----+    &nbs= p;  |     Mo    |   .

     &nbs= p;            &= nbsp;     .       &n= bsp;       +-----------+   = .

     &nbs= p;            &= nbsp;     .       &n= bsp;            = ;           .<= /span>

     &nbs= p;            &= nbsp;     . . . . . . . . . . . . . . . . .<= /span>

     &nbs= p;            &= nbsp;     example.org domain

 

     &nbs= p;            &= nbsp;   Figure 13: Recursive Signaling

&n= bsp;

&n= bsp;

We do h= ave this text (that may be tweaked):

&n= bsp;

   In ord= er to prevent leaking internal information outside a client-

   domain= , DOTS gateways located in the client-domain SHOULD NOT reveal

   the id= entification information that pertains to internal DOTS clients<= /span>

   (clien= t-identifier) unless explicitly configured to do so.

[Jon4] I had always read this as being a DOTS gateway on t= he border of a different client and server domain

[Med] T= he mention which is important in that text is: “DOTS gateways located in the client-domain”.

&n= bsp;

[Jon3] “Client-side DOTS gateways” may, or may= not, want to pass on “client-identifiers” (which are obfuscate= d to hide identity).  If they do not pass on “client-identifiers= ” then the DOTS server they connect to (which is in the same domain by defin= ition) will not be able to differentiate between the different clients R= 11; the whole purpose of “client-identifiers” – or am I m= issing something here?

[Med] F= or client-side DOTS gateways, the server does not need to rely upon the ide= ntity of internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS cli= ents and a DOTS gateway located on the CPE that intercepts all messages fro= m these clients. The ultimate DOTS server does not to know about those DOTS= clients.<= /span>

[Jon4] Again an example of a DOTS gateway that sits both i= n a client and (different) server domain.

[Med] T= he CPE is in the border from a connectivity standpoint, but for DOTS, the g= ateway is under the control of the client. I don’t see the “server domain” part in this example.  

&n= bsp;

&n= bsp;

[Jon3] To me, the only time that “client-identifiers= ” may need to be dropped (not that I recommend doing this) is when a = DOTS Gateway is sitting in both a client’s domain and a different server’s domain as a domain border gateway.

&n= bsp;

“= to propagate the DOTS client identity from the gateway's

   &= nbsp;  client-side to the gateway's server-side, and from the gateway'= s

   &= nbsp;  server-side to the DOTS server. ”

&n= bsp;

   &= nbsp;  DOTS gateway in a manner that ensures that there is zero

   &= nbsp;  probability that the same value will be assigned to a different=

   &= nbsp;  DOTS client.  The server-side DOTS gateway MUST conceal

   &= nbsp;  potentially sensitive DOTS client identity information.

 

   &= nbsp;  If aggregating DOTS mitigation requests received from multiple<= o:p>

   &= nbsp;  DOTS clients is enabled, the server-side DOTS gateway has to in= clude

   &= nbsp;  a list of 'client-identifier' values; each value is pointing to= a

   &= nbsp;  DOTS client.  It is out of scope of this document to speci= fy how

[Jon1] I prefer “a list of 'client-identifier' value= s; each value is pointing to a unique

      DOTS client that is in the = aggregated list.  It is out of….”

&n= bsp;

[Med] D= eal.  

&n= bsp;

   &= nbsp;  aggregation is implemented by a DOTS gateway.=

 

   &= nbsp;  The client-identifier attribute MUST NOT be generated and inclu= ded

   &= nbsp;  by DOTS clients.

 

   &= nbsp;  DOTS servers MUST ignore client-identifier attributes that are<= o:p>

   &= nbsp;  directly supplied by source DOTS clients.  This implies th= at first

   &= nbsp;  server-side DOTS gateways MUST strip client-identifier attribut= es

   &= nbsp;  supplied by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS clie= nt and the client component of a DOTS gateway (i.e. server-facing-side) as = seen by a DOTS server?  There is nothing that I have spotted for this in the DOTS signal protocol.

&n= bsp;

[Med] I= confirm, there is no such text in the draft. A deployment would consist in= explicitly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is coming= from a server-side gateways in that list.

 

[Jon2] Then do we need to instruct the implementers of the= signal channel that this is what should be done?

[Med] W= hat about adding this text:

&n= bsp;

NEW:

   &= nbsp;  DOTS servers MAY support a

   &= nbsp;  configuration parameter (e.g., ACLs) to identify DOTS gateways<= o:p>

   &= nbsp;  that are trusted to supply client-identifier attributes.

[Jon4] I do not think ACL is the right term here.  In= the same way the a DOTS server needs to know the valid client IDs of the D= OTS clients that can use it (along with the valid target IP addresses etc.) “valid gateway” could be added= in.  I would just drop “(e.g. ACLS)”.

[Med] D= ropped.

=  

[Jon1] I do agree that true DOTS clients MUST NOT generate= ‘client-identifiers’. If only the DOTS gateway server componen= t (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this = issue as it is only the DOTS server component who is allowed to do the gene= ration.

 

[Jon1] In my implementation the DOTS server (gateway or no= t) always generates a client-identifier (will be changed if there already i= s a unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can = differentiate between the same mitigation-id from different clients.

[Med] O= k, thanks.

 

   &= nbsp;  This is an optional attribute.

 

2nd change: Delete t= his text because client-identifier is uniquely assigned by the first server= -side gateway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

   If the= 'client-identifier' value is already present in the

   mitiga= tion request received from the DOTS client, the DOTS gateway

   MAY co= mpute the 'client-identifier' value, as discussed above, and

   add th= e computed 'client-identifier' value to the end of the 'client-<= /span>

   identifier' list.

[Jon1] OK

 

Comments and modifications are = more welcome.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.o= rg; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …but broken clients= may communicate directly with servers without any gateway on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actually,

=B7    &n= bsp;    (R1) we do need MUST so= that as a general rule clients do not insert a client-id parameter in thei= r requests.

=B7    &n= bsp;    And (R2) DOTS servers M= UST ignore client-ids that are supplied by the origin DOTS clients.

 

In deployments without gateways= , client-ids supplied by broken DOTS clients will be ignored by the server = as per R2.

In deployments with gateways, t= he first server-side gateway will follow R2 and strip any value supplied by= the client.

 

If we add text to cover (R2), I= don’t think we need a sentence about updating the content because cl= ient-id is a value that is ***assigned*** exclusively by a dots gateway:

 

   &= nbsp;  The 'client-identifier' value MUST be assigned by the DOTS gate= way

   &= nbsp;           &nbs= p;            &= nbsp;       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^  

   &= nbsp;  in a manner that ensures that there is zero probability th= at the

   &= nbsp;  same value will be assigned to a different DOTS client. 

 

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for sharing your thou= ghts.

 

Please see comments inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There are also some compl= ications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client (C1aj) -----------= -------------------------- (S1j) DOTS gateway J (C2j) ----------\ &nbs= p;

DOTS client (C1bj) -----------= -----------------------------/       &nb= sp;             = ;            &n= bsp;|

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;|

DOTS client (C1ax) ----- (S1x)= DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3) &n= bsp; 

DOTS client (C1bx) --------/&n= bsp;            = ;            &n= bsp;     |      &nbs= p;            &= nbsp;           

     =             &nb= sp;            =             &nb= sp;            =     |        &n= bsp;            = ;            

DOTS client (C1ay) ----- (S1y)= DOTS gateway Y (C2y) -------/       &nb= sp;            =              

DOTS client (C1by) --------/&n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOT= S forwarding path will always be the same (that is, the same set of gateway= s will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree for the first serve= r-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this design in a multi-homing scenario with the same mitigation provider: the same request from a multi-= homed DOTS client will be presented to the server as being distinct request= s…while this is not. It may be the same request that is forked among = existent network attachments or a request that is sent over a first link, but a subsequent one over another link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’m referring to th= is “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, these are deploymen= t-specific. My concern is to avoid design choices that make hidden assumpti= ons.  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation).    

 

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we agree that one (uni= que) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess you meant “= restrict the number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would say this is deployment-specific. A deployment that enables signal/data cha= nnel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please note that I used &= #8220;good/bad deployment choices&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 

To avoid potential conflicts and also in or= der to help the server select the appropriate policy to enforce, signal/dat= a channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter to carry= multiple values.

 

Putting aside the extensibility argument of= the data model, the signal/data channel protocol drafts are silent about t= he exact use of multiple values.

 

The potential deployment cases for multiple= values are (without making any assumption whether these cases are good/bad= deployment choices):

 

(1)<= /span>Multiple gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)<= /span>Requests from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 

The current approach has the merit to not m= ake any assumption on the gateway behavior (e.g., (2)), but it leads to a c= onfusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS = clients or to a DOTS client and a set of on-path gateways. The protocol doc= uments need to be updated to avoid such confusion. Two options are listed b= elow:

 

Option 1 (Avoid making any assumption on ga= teways/proper semantic distinction between clients and on-path gateways)

-    Restrict the usage of ‘client= -identifier’ to carry identifiers of clients, not gateways.

-    On-path gateways may include a new = parameter called ‘gateway-identifier’ to ease contexts retrieva= l and avoid potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with ‘clie= nt-identifier’ pointing to C

G2 will update the request with ‘gate= way-identifier’ pointing to G1

 

Option 2 (Describe what a gateway cannot do= )

-    Update the architecture document to= indicate that requests are not aggregated by a dots gateway.

-    ‘client-identifier’ inc= ludes multiple values only and only if multiple gateways are on-path. The o= rder of the values is important because the first one will be the one pointing to the source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with ‘clie= nt-identifier’ pointing to C

G2 will update the request with ‘clie= nt-identifier’ pointing to G1 (in addition to C)

 

We are seeking for feedback from the WG on = which direction to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

--_000_787AE7BB302AE849A7480A190F8B93300A09A920OPEXCLILMA3corp_-- From nobody Tue Dec 19 01:56:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C712812D892 for ; Tue, 19 Dec 2017 01:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiuNsCwRtos9 for ; Tue, 19 Dec 2017 01:56:43 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96B712421A for ; Tue, 19 Dec 2017 01:56:42 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eREda-0004yH-MA; Tue, 19 Dec 2017 09:56:39 +0000 From: "Jon Shallow" To: , , "kaname nishizuka" References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <031001d3781d$55f34f70$01d9ee50$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A920@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A920@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 19 Dec 2017 09:56:39 -0000 Message-ID: <036f01d378af$aa8550f0$ff8ff2d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0370_01D378AF.AA8EC6D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQL78MMpr/pdhlrC37/cibvPBYF7nANCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTETAkWEwxEDVu2BwAILYvd7Ajb4MCQBNYeI1QJ2o5bloBAowxA= Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 09:56:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0370_01D378AF.AA8EC6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 =93[Med] I suspect the disconnect is caused by mixing connectivity and = DOTS control aspects=94 =20 Ahh =96 the light bulb has gone off =96 why our discussions had a = disconnect. It is down to the interpretation of the word =93side=94 as used in = =93Client Side DOTS gateway=94. To you it meant =93control or ownership=94, to me = =93connectivity or position relative to DOTS gateway=94. =20 To prevent others getting confused, my suggestion would be to update the following in the various draft specs =20 =93Client-Side DOTS Gateway=94 to =93Client Domain Managed DOTS = gateway=94 =93Server-Side DOTS Gateway=94 to =93Server Domain Managed DOTS = gateway=94 =93DOTS gateway server-side=94 to =93DOTS gateway server-facing-side=94 =93DOTS gateway client-side=94 to =93DOTS gateway client-facing-side=94 =20 The latter 2 should be defined somewhere. =20 To me, a gateway is a border of some sort =96 where there is a potential discontinuity of flow (e.g. aggregation, client/server etc.) =20 Otherwise, see inline [Jon5]. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 07:15 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 17:29 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med, =20 See inline [Jon4]. I have deleted some of the =93see inline = messages=94. =20 Regards =20 Jon =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med, =20 Going in the right direction, but see comments inline [Jon1]. =20 As a side comment, I always have to think twice what =93DOTS gateway server-side=94 actually means. It actually means the DOTS client = component logic of a DOTS gateway. There is no definition of terms in the signal channel draft, but the definition could perhaps be added to the dots requirements draft. Others may also get confused about this. Perhaps = =93DOTS gateway server-facing-side=94 is clearer, even though much longer to = type! =20 [Med] We do have the following definition in the requirements I-D:=20 =20 Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. =20 =20 [Jon2] Yes =96 actually, this adds to the confusion in my mind. For a singular DOTS gateway, it could have a client-facing-side that is in the DOTS client domain, and a server-facing side that is in a different DOTS server domain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for = the =93client-facing side=94 of a gateway to belong to the client domain and = its =93server-facing side=94 to belong to the server domain?=20 [Jon3]The recursive gateway comes immediately to mind =96 when an ISP = cannot handle the current attack and wants to invoke someone else to handle it. Otherwise to me, a gateway to me is either an aggregation point of = clients within a common domain or a border between two different domains. [Med] Given that recursive signalling is opaque to the origin DOTS = client, all involved gateways are IMHO at the server-side (from the perspective = of the source client). The only difference is that the intermediate dots gateway (server) is managed by Provider 1 while the final server is = managed by another provider. [Jon4] Hmm =96 I am not convinced. Some of your examples below actually = give examples for a DOTS gateway sitting in both client and (different) = server domains. [Med] I suspect the disconnect is caused by mixing connectivity and DOTS control aspects. [Jon5] Thanks =96 this is the cause of our disconnect in interpretation = of =93side=94 =96 well spotted =20 [Jon2] Also, being picky, does =93Client-side DOTS gateway=94 (type of = DOTS gateway) actually mean the same as =93DOTS gateway client-side=94 = (component within a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - =93xxx-side DOTS gateway=94 means this is owned and operated by = xxx. - =93DOTS gateway client-side=94 refers to the client-facing = interface of a DTOS gateway. It applies for both client- and server-side getaways. =20 [Jon3] I agree with your distinct definitions, but not the use of the definition in the requirements I-D to cover the definition of =93DOTS = Gateway client-side=94 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Jon,=20 =20 Please see below two proposed changes to hopefully conclude on the = issues discussed in this thread: =20 1st change:=20 =20 OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. =20 The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. =20 This is an optional attribute. =20 NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. =20 The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway = are separate (the server-facing component has no real knowledge of what is happening on the client-facing side), it needs to be the = client-facing-side of the DOTS gateway that assigns the (unique) client-identifier which is then passed over to the server-facing-side for onward transmission. =20 [Med] You are right if we zoom on the internal implementation of a DOTS gateway. This part of the text focuses on the external behavior of the = DOTS gateway. The text does not need to zoom in given that the second = sentence above says;=20 =20 [Jon2] In terms of helping the implementers, the use of only DOTS server being allowed to generate a =91client-identifier=92 as discussed later. = If =93server-side=94 was removed as in :- =93client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity =85=94 Removes a lot of confusion in my mind. =20 [Med] The =93server-side=94 is important because we don=92t want = client-side GWs to reveal the identity of internal dots clients.=20 [Jon3] Why do we need to be restrictive to =93Server-side DOTS = gateways=94 here? [Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients = are deployed in the client=92s domain. [Jon4] But all this (deployment etc.) information is in the client = domain only using your definition of a client-side DOTS gateway =96 so within = the client space who the really cares? [Jon4] But this information going into another domain is the security concern. However, to get a mitigation request to go between domains, = there has to be a border at some point. How do we handle that? What does the border look like (it cannot be a client-side or server-side DOTS gateway = as that is not allowed to straddle domains as you assert)?=20 [Med] It looks like what is described in the architecture draft: a = gateway located in the server-side. =20 example.net domain . . . . . . . . . . . . . . . . . . Gn . +----+ 1 . +----+ +-----------+ . | Cc |<--------->| Sn |~~~~~~~| Mitigator | . +----+ . +=3D=3D=3D=3D+ | Mn | . . | Cn | +-----------+ . example.com . +----+ . client . ^ . . . .|. . . . . . . . . . . . . . | 1 | | . . .|. . . . . . . . . . . . . . . v . . +----+ +-----------+ . . | So |~~~~~~~| Mitigator | . . +----+ | Mo | . . +-----------+ . . . . . . . . . . . . . . . . . . . . example.org domain =20 Figure 13: Recursive Signaling [Jon5] Note: It is possible that Cc actually is a gateway =96 which = would be client managed and is the border point =20 We do have this text (that may be tweaked):=20 =20 In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. [Jon4] I had always read this as being a DOTS gateway on the border of a different client and server domain [Med] The mention which is important in that text is: =93DOTS gateways = located in the client-domain=94. [Jon5] Agreed. However, if there are multiple gateways in the chain, = all client managed, it is only the one on the border with a server domain = that needs to be extra careful. =20 [Jon3] =93Client-side DOTS gateways=94 may, or may not, want to pass on =93client-identifiers=94 (which are obfuscated to hide identity). If = they do not pass on =93client-identifiers=94 then the DOTS server they connect = to (which is in the same domain by definition) will not be able to differentiate between the different clients =96 the whole purpose of = =93client-identifiers=94 =96 or am I missing something here? [Med] For client-side DOTS gateways, the server does not need to rely = upon the identity of internal DOTS clients; the identity of the gw is = sufficient. Imagine an enterprise network with multiple DOTS clients and a DOTS = gateway located on the CPE that intercepts all messages from these clients. The ultimate DOTS server does not to know about those DOTS clients. [Jon4] Again an example of a DOTS gateway that sits both in a client and (different) server domain. [Med] The CPE is in the border from a connectivity standpoint, but for = DOTS, the gateway is under the control of the client. I don=92t see the = =93server domain=94 part in this example. [Jon5] Again a disconnect in our interpretation, now understood. To me = the gateway (albeit it client managed) is the border between the client and server domains. =20 =20 =20 [Jon3] To me, the only time that =93client-identifiers=94 may need to be = dropped (not that I recommend doing this) is when a DOTS Gateway is sitting in = both a client=92s domain and a different server=92s domain as a domain border gateway. =20 =93to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. =94 =20 DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. =20 If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to = include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer =93a list of 'client-identifier' values; each value is pointing to a unique DOTS client that is in the aggregated list. It is out of=85.=94 =20 [Med] Deal. =20 =20 aggregation is implemented by a DOTS gateway. =20 The client-identifier attribute MUST NOT be generated and included by DOTS clients. =20 DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the = client component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server? There is nothing that I have spotted for this in the DOTS = signal protocol. =20 [Med] I confirm, there is no such text in the draft. A deployment would consist in explicitly configuring a list of gateways (ACLs) on the = server; the server will trust client-id if and only if it is coming from a server-side gateways in that list. =20 [Jon2] Then do we need to instruct the implementers of the signal = channel that this is what should be done? [Med] What about adding this text:=20 =20 NEW:=20 DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon4] I do not think ACL is the right term here. In the same way the a DOTS server needs to know the valid client IDs of the DOTS clients that = can use it (along with the valid target IP addresses etc.) =93valid = gateway=94 could be added in. I would just drop =93(e.g. ACLS)=94. [Med] Dropped.=20 =20 [Jon1] I do agree that true DOTS clients MUST NOT generate =91client-identifiers=92. If only the DOTS gateway server component (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is only = the DOTS server component who is allowed to do the generation. =20 [Jon1] In my implementation the DOTS server (gateway or not) always generates a client-identifier (will be changed if there already is a = unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differentiate between the same mitigation-id from different clients. [Med] Ok, thanks. =20 This is an optional attribute. =20 2nd change: Delete this text because client-identifier is uniquely = assigned by the first server-side gateway; there is no need to prepend = identifiers computed by other gateways.=20 =20 OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK=20 =20 Comments and modifications are more welcome.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Re-, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med / Kaname, =20 =93I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client.=94 We do need to handle the case of a broken client (how does the DOTS = server know it is a DOTS gateway client or a real DOTS client?) who does not = obey the MUST. [Med] =85but broken clients may communicate directly with servers = without any gateway on the path.=20 =20 =93The client-identifier attribute SHOULD NOT be generated and included = by the DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.=94 =20 Is the safer option for me. =20 [Med] Actually,=20 =B7 (R1) we do need MUST so that as a general rule clients do = not insert a client-id parameter in their requests.=20 =B7 And (R2) DOTS servers MUST ignore client-ids that are = supplied by the origin DOTS clients.=20 =20 In deployments without gateways, client-ids supplied by broken DOTS = clients will be ignored by the server as per R2.=20 In deployments with gateways, the first server-side gateway will follow = R2 and strip any value supplied by the client.=20 =20 If we add text to cover (R2), I don=92t think we need a sentence about updating the content because client-id is a value that is ***assigned*** exclusively by a dots gateway: =20 The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = =20 in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. =20 =20 Otherwise, see [Jon] inline (8 times). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Jon,=20 =20 Thank you for sharing your thoughts.=20 =20 Please see comments inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi Med and all, =20 I think that =91gateway-identifier=92 is likely to cause more confusion = and will not actually help to try and solve what I perceive is the underlying = issue that has triggered this discussion - =93How do we handle = =91client-identifiers=92 when a DOTS gateway does aggregation?=94 [Med] There are also some complications even when no aggregation is in = use. See below.=20 =20 . I am leaning towards your Option 2. Some of my reasoning is below. =20 Background to client-identifiers. =20 In the general case (e.g. no DOTS gateway aggregation of filters / = aliases etc.), every time a request or update (both signal and data) passes = upstream through a DOTS gateway, an additional =91client-identifier=92 is added = to the request / update. The final DOTS server can then uniquely identify the request / update as coming from a specific Client and exactly match, = say, an (possibly non unique alias-name) alias definition sent over the data = channel with a (possibly non unique mitigation-id) mitigation request using the = same alias-name sent over the signal channel. =20 Client Identification Usage Example =20 DOTS client (C1aj) ------------------------------------- (S1j) DOTS = gateway J (C2j) ----------\ =20 DOTS client (C1bj) ----------------------------------------/ | =20 | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS = gateway K (C3k) -------- (S3) =20 DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ =20 Where CI is =91client-identifier=92 =96 a unique hash of the client = identification :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)] =20 [Med] This assumes that the DOTS forwarding path will always be the same (that is, the same set of gateways will be solicited for requests coming from a given DOTS client). =20 [Jon] The current text states =93If the 'client-identifier' value is = already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list.=94 =20 [Jon] The MAY is not a MUST for the simple reason that if the original = DOTS client client-identifier is computed correctly, it should be unique all = the way through the different DOTS gateways (so no additional = client-identifiers need to get added) so that S3 just sees [alias-name=3DServer1&client-identifer=3DCI(C1ax)]. The DOTS gateways = in the path can then change over time with no issues. =20 [Jon] All that is required then is that a DOTS gateway makes sure that = any Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional client-identifiers = (but still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway.=20 =20 [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier = =96 even if it is the first in the chain if it wants to hide the client information, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as client-identifiers, if created properly, obfuscate the actual client information. =20 [Med]I do see some implications of this design in a multi-homing = scenario with the same mitigation provider: the same request from a multi-homed = DOTS client will be presented to the server as being distinct = requests=85while this is not. It may be the same request that is forked among existent network attachments or a request that is sent over a first link, but a = subsequent one over another link. =20 [Jon] Perhaps I am missing something here, but I would be expecting a multi-homed device to be using the same PKI certificate (or equivalent) = in which case the client-identifier (which is not IP based) would be the = same over the different network interfaces. =20 [Med] I=92m referring to this =93[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]=94.= =20 [Jon] If however, the different network interfaces are connected to different DOTS provider domains, then there will be multiple PKI certs, = and hence different client-identifiers propagating up to the DOTS servers = =96 but as these are different provider domains will they ever join up into a = common domain? If they do, then this is where you could be getting conflicting requests =96 subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design choices that make hidden assumptions. =20 =20 =20 [Med] Separating both client-id from gateway-id does not suffer from = this issue (even when no aggregation). =20 =20 [Jon] Yes =96 the assumption being that all the client-identifiers are = unique =96 In which case I argue again that additional information =96 e.g. gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I=92m = fine.=20 =20 so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with = same alias name) S3 can differentiate them all based on the different CI(). =20 Then when C1ax requests a mitigation with alias-name=3DServer1, by the = time the request gets to S3, S3 can match the alias-name definition in the mitigate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]. =20 If C1aj also requests a mitigation with alias-name=3DServer1, S3 will = see the alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] = and match accordingly. =20 As responses come back from S3 to the originating client, the = appropriate CI(cxxx) gets stripped off so the originating client sees no =91client-identifier=92 fields at all. =20 This general solution is simple with only one disadvantage =96 there is = a limit of 20 - 24 client-identifiers (20 =96 24 DOTS gateways) that will = fit into a single UDP packet due to MTU restrictions. However in practice = there are unlikely to be this number of DOTS gateways. The count varies based = on how much other information needs to be put into the packet. =20 DOTS Gateway Session aggregation =20 There is no reason as to why multiple DOTS clients=92 signal and data = requests cannot be multiplexed into a single session on the DOTS gateway to DOTS server connection =96 especially as different client-identifiers = separate out the different requests / responses. =20 This session aggregation is not the same as signal / data aggregation =20 NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation =20 [Med] Agree.=20 =20 DOTS Gateway signal / data aggregation challenges =20 Individual clients in general will generate their unique mitigation = requests =96 but may have common information (e.g. same protocol, ports, = alias-name). If the mitigation requests are not unique then we have potential = conflicts =96 not part of this discussion. =20 Aggregating (unique) mitigation requests on a DOTS gateway could be a programmatic challenge, unless it is the simple aggregation of all the different target-prefixes =96 aggregating different port requirements = for different target-prefixes gets more interesting=85.. This adds in a lot = of potential complexity with potential for boundary condition error issues. =20 Aggregation of Filters is at first sight relatively simple - but there = then may be ordering challenges / conflicts =96 e.g. one filter has an IP = that is a white-list, and another has the same IP as a black-list =96 both valid = in the respective client environment. Ordering of conflicting filter = information is important and I am not sure that a DOTS gateway will do this = properly unless it either has some hints or complex rules to work with =96 just = adding in complexity where more things can potentially go wrong. =20 Use of gateway-identifier and client-identifier combination can be used = to partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), but again we are limited to 20 =96 24 *-identifiers in total due to packet MTU. Even if = we for example say that there is a maximum of 4 DOTS gateways allowed, we then limit the number of clients that can be aggregated to 16 =96 20. Do we = really want to restrict the number of supported DOTS clients per DOTS gateway = if aggregation is supported? =20 [Med] I guess you meant =93restrict the number of aggregated clients per = DOTS gateway=94, not the =93number of DOTS clients serviced by a DOTS = gateway=94. I would say this is deployment-specific. A deployment that enables = signal/data channel aggregation is aware of this limitation.=20 =20 [Jon] Yes, that is better phrasing. [Med] OK.=20 =20 I still struggle with how do you actually do the aggregation (merging = of data/signal) at any gateway other than in a couple of simple cases out = of the many different scenarios. [Med] Please note that I used =93good/bad deployment choices=94 in the = initial message. Merging the requests will induce some complexity at the = gateway, sure. From a protocol standpoint, I=92m trying to be neutral on this. My = main concern is to avoid making choices in the protocol that will have = deployment implications. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation =20 Hi all,=20 =20 To avoid potential conflicts and also in order to help the server select = the appropriate policy to enforce, signal/data channel protocol drafts = specify a parameter called =93client-identifier=94. The design allows this = parameter to carry multiple values.=20 =20 Putting aside the extensibility argument of the data model, the = signal/data channel protocol drafts are silent about the exact use of multiple = values.=20 =20 The potential deployment cases for multiple values are (without making = any assumption whether these cases are good/bad deployment choices): =20 (1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discusses recursive signaling and also = cases where multiple DOTS gateways are involved.=20 (2)Requests from multiple clients may be aggregated by the same = server-side into one single request forwarded to the upstream server. For example, filtering rules received from multiple clients of the same domain may be aggregated in one single request. =20 =20 The current approach has the merit to not make any assumption on the = gateway behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients or to a DOTS client and a set of on-path gateways. The protocol documents need to be updated to avoid such = confusion. Two options are listed below:=20 =20 Option 1 (Avoid making any assumption on gateways/proper semantic distinction between clients and on-path gateways) - Restrict the usage of =91client-identifier=92 to carry identifiers = of clients, not gateways.=20 - On-path gateways may include a new parameter called =91gateway-identifier=92 to ease contexts retrieval and avoid potential collisions. =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91gateway-identifier=92 pointing to G1 =20 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not aggregated by a dots gateway. - =91client-identifier=92 includes multiple values only and only if = multiple gateways are on-path. The order of the values is important because the = first one will be the one pointing to the source DOTS clients.=20 =20 An example is provided below:=20 =20 C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS =20 G1 will update the request with =91client-identifier=92 pointing to C G2 will update the request with =91client-identifier=92 pointing to G1 = (in addition to C) =20 We are seeking for feedback from the WG on which direction to take.=20 =20 Thoughts? =20 Cheers, Med =20 =20 =20 ------=_NextPart_000_0370_01D378AF.AA8EC6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

“[Med] I suspect the disconnect is caused by = mixing connectivity and DOTS control = aspects”

 

Ahh – the light bulb = has gone off – why our discussions had a disconnect.=A0 It is down = to the interpretation of the word “side” as used in = “Client Side DOTS gateway”.=A0 To you it meant = “control or ownership”, to me “connectivity or = position relative to DOTS gateway”.

 

To prevent others getting = confused, my suggestion would be to update the following in the various = draft specs

 

“Client-Side DOTS = Gateway” to “Client Domain Managed DOTS = gateway”

“Server-Side DOTS Gateway” to = “Server Domain Managed DOTS gateway”

“DOTS gateway = server-side” to “DOTS gateway = server-facing-side”

“DOTS gateway = client-side” to “DOTS gateway = client-facing-side”

 

The latter 2 should be = defined somewhere.

 

To me, a gateway is a = border of some sort – where there is a potential discontinuity of = flow (e.g. aggregation, client/server etc.)

 

Otherwise, see inline = [Jon5].

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 19 December 2017 = 07:15
To: Jon Shallow; dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] =
Envoy=E9 : lundi 18 d=E9cembre 2017 = 17:29
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; = kaname nishizuka
Objet : RE: [Dots] client-identifier: = Recurisve signaling & = Aggregation

 

Hi Med,

 

See inline [Jon4].  = I have deleted some of the “see inline = messages”.

 

Regards

 

Jon

 

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi = Med,

 

Going in the right = direction, but see comments inline [Jon1].

 

As a side comment, I = always have to think twice what “DOTS gateway server-side” = actually means.  It actually means the DOTS client component = logic of a DOTS gateway.  There is no definition of terms in the = signal channel draft, but the definition could perhaps be added to the = dots requirements draft.  Others may also get confused about = this.  Perhaps “DOTS gateway server-facing-side” is = clearer, even though much longer to type!

 

[Med] We do have the following definition in = the requirements I-D:

 

      = Client-side DOTS gateways

      are = DOTS gateways that are in the DOTS client's domain, = while

      = server-side DOTS gateways denote DOTS gateways that are in = the

      = DOTS server's = domain.

 

 

[Jon2] Yes – = actually, this adds to the confusion in my mind.  For a singular = DOTS gateway, it could have a client-facing-side that is in the DOTS = client domain, and a server-facing side that is in a different DOTS = server domain.  The quoted text implies it is one or the other, but = not both.

[Med] Do you have a particular case in mind in = which we should allow for the “client-facing side” of a = gateway to belong to the client domain and its “server-facing = side” to belong to the server domain?

[Jon3]The recursive = gateway comes immediately to mind – when an ISP cannot handle the = current attack and wants to invoke someone else to handle it.  = Otherwise to me, a gateway to me is either an aggregation point of = clients within a common domain or a border between two different = domains.

[Med] Given that recursive signalling is = opaque to the origin DOTS client, all involved gateways are IMHO at the = server-side (from the perspective of the source client). The only = difference is that the intermediate dots gateway (server) is managed by = Provider 1 while the final server is managed by another = provider.

[Jon4] Hmm – I am = not convinced.  Some of your examples below actually give examples = for a DOTS gateway sitting in both client and (different) server = domains.

[Med] I suspect the disconnect is caused by = mixing connectivity and DOTS control aspects.

[Jon5] Thanks – = this is the cause of our disconnect in interpretation of = “side” – well spotted

 

[Jon2] Also, being = picky, does “Client-side DOTS gateway” (type of DOTS = gateway) actually mean the same as “DOTS gateway = client-side” (component within a DOTS = gateway)?

[Med] No. Those are two distinct = things/dimensions:

-    = “xxx-side DOTS gateway” means this = is owned and operated by xxx.

-    = “DOTS gateway client-side” refers = to the client-facing interface of a DTOS gateway. It applies for both = client- and server-side getaways.  

[Jon3] I agree with your = distinct definitions, but not the use of the definition in the = requirements I-D to cover the definition of “DOTS Gateway = client-side”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 13:04
To: Jon Shallow; = dots@ietf.org; kaname = nishizuka
Subject: Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Jon,

 

Please see below two proposed changes to = hopefully conclude on the issues discussed in this = thread:

 

1st change: =

 

OLD:

   = client-identifier:  The client identifier MAY be conveyed by the = DOTS

      = gateway to propagate the DOTS client identity from the = gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server.  This allows the DOTS server = to

      = accept mitigation requests with scopes which the DOTS client = is

     autho= rized to manage.

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      in = a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  The = DOTS

      = gateway MUST conceal potentially sensitive DOTS client = identity

      = information.  The client-identifier attribute SHOULD NOT = be

      = generated and included by the DOTS client.

 

      = This is an optional attribute.

 

NEW:

   = client-identifier:  The client identifier MAY be conveyed by = a

      = server-side DOTS gateway to propagate the DOTS client = identity

      = from the gateway's client-side to the gateway's server-side, = and

      = from the gateway's server-side to the DOTS server. = 'client-

      = identifier' MAY be used by the final DOTS server for = policy

      = enforcement purposes.

 

      The = 'client-identifier' value MUST be assigned by the = server-side

[Jon1]  Actually, = as the client and server components of a DOTs gateway are separate (the = server-facing component has no real knowledge of what is happening on = the client-facing side), it needs to be the client-facing-side of the = DOTS gateway that assigns the (unique) client-identifier which is then = passed over to the server-facing-side for onward = transmission.

 

[Med] You are right if = we zoom on the internal implementation of a DOTS gateway. This part of = the text focuses on the external behavior of the DOTS gateway. The text = does not need to zoom in given that the second sentence above says; =

 <= /p>

[Jon2] In terms of = helping the implementers, the use of only DOTS server being allowed to = generate a ‘client-identifier’ as discussed later.  If = “server-side” was removed as in :-

“client-identifier:=   The client identifier MAY be conveyed by = a

    &= nbsp; DOTS gateway to propagate the DOTS client identity = …”

Removes a = lot of confusion in my mind.

 

[Med] The = “server-side” is important because we don’t want = client-side GWs to reveal the identity of internal dots clients. =

[Jon3] Why do we need to = be restrictive to “Server-side DOTS gateways” = here?

[Med] For privacy = concerns: e.g., avoid revealing how/where DOTS clients are deployed in = the client’s domain.

[Jon4] But all this = (deployment etc.) information is in the client domain only using your = definition of a client-side DOTS gateway – so within the client = space who the really cares?

<= p class=3DMsoNormal>[Jon4] But this = information going into another domain is the security concern.  = However, to get a mitigation request to go between domains, there has to = be a border at some point.  How do we handle that?  What does = the border look like (it cannot be a client-side or server-side DOTS = gateway as that is not allowed to straddle domains as you assert)? =

[Med] It looks like = what is described in the architecture draft: a gateway located in the = server-side.

 

      = ;            =       example.net = domain

      = ;            =       . . . . . . . . . . . . . . . . = .

      = ;            =       .    = Gn            = ;            = .

      = ;    +----+    1   .  = +----+       +-----------+   = .

      = ;    | Cc |<--------->| Sn |~~~~~~~| Mitigator = |   .

      = ;    +----+        = .  +=3D=3D=3D=3D+       = |     Mn    |   = .

      = ;            =       .  | Cn = |       +-----------+   = .

      = ;  example.com     .  = +----+           &= nbsp;           = .

      = ;     client       = .    = ^           =             &= nbsp;  .

      = ;            =       . . .|. . . . . . . . . . . . . = .

      = ;            =            = |

      = ;            =          1 = |

      = ;            =            = |

      = ;            =       . . .|. . . . . . . . . . . . . = .

      = ;            =       .    = v            =             &= nbsp; .

      = ;            =       .  = +----+       +-----------+   = .

      = ;            =       .  | So |~~~~~~~| Mitigator = |   .

      = ;            =       .  = +----+       |     = Mo    |   .

      = ;            =       = .            =    +-----------+   .

      = ;            =       = .            =             &= nbsp;      .

      = ;            =       . . . . . . . . . . . . . . . . = .

      = ;            =       example.org = domain

 

      = ;            =     Figure 13: Recursive = Signaling

[Jon5] Note: It is = possible that Cc actually is a gateway – which would be client = managed and is the border point

 

We do have this text = (that may be tweaked):

 

   In order to prevent = leaking internal information outside a client-

   domain, DOTS gateways = located in the client-domain SHOULD NOT reveal

   the identification = information that pertains to internal DOTS = clients

   (client-identifier) = unless explicitly configured to do so.

[Jon4] I had always read = this as being a DOTS gateway on the border of a different client and = server domain

[Med] The mention = which is important in that text is: “DOTS gateways located in the = client-domain”.

[Jon5] Agreed.=A0 = However, if there are multiple gateways in the chain, all client = managed, it is only the one on the border with a server domain that = needs to be extra careful.

=

 

[Jon3] = “Client-side DOTS gateways” may, or may not, want to pass on = “client-identifiers” (which are obfuscated to hide = identity).  If they do not pass on “client-identifiers” = then the DOTS server they connect to (which is in the same domain by = definition) will not be able to differentiate between the different = clients – the whole purpose of “client-identifiers” = – or am I missing something here?

[Med] For client-side = DOTS gateways, the server does not need to rely upon the identity of = internal DOTS clients; the identity of the gw is sufficient. Imagine an = enterprise network with multiple DOTS clients and a DOTS gateway located = on the CPE that intercepts all messages from these clients. The ultimate = DOTS server does not to know about those DOTS clients.

[Jon4] Again an example = of a DOTS gateway that sits both in a client and (different) server = domain.

[Med] The CPE is in = the border from a connectivity standpoint, but for DOTS, the gateway is = under the control of the client. I don’t see the “server = domain” part in this example.

[Jon5] Again a = disconnect in our interpretation, now understood.=A0 To me the gateway = (albeit it client managed) is the border between the client and server = domains.

=  

 

 

[Jon3] To me, the only = time that “client-identifiers” may need to be dropped (not = that I recommend doing this) is when a DOTS Gateway is sitting in both a = client’s domain and a different server’s domain as a domain = border gateway.

<= p class=3DMsoNormal> 

“to propagate the DOTS client = identity from the gateway's

      = client-side to the gateway's server-side, and from the = gateway's

      = server-side to the DOTS server. ”

 

      = DOTS gateway in a manner that ensures that there is = zero

      = probability that the same value will be assigned to a = different

      = DOTS client.  The server-side DOTS gateway MUST = conceal

      = potentially sensitive DOTS client identity = information.

 

      If = aggregating DOTS mitigation requests received from = multiple

      = DOTS clients is enabled, the server-side DOTS gateway has to = include

      a = list of 'client-identifier' values; each value is pointing to = a

      = DOTS client.  It is out of scope of this document to specify = how

[Jon1] I prefer “a = list of 'client-identifier' values; each value is pointing to a = unique

    &= nbsp; DOTS client that is in the aggregated list.  It is out = of….”

 

[Med] Deal. =  

 

      = aggregation is implemented by a DOTS gateway.

 

      The = client-identifier attribute MUST NOT be generated and = included

      by = DOTS clients.

 

      = DOTS servers MUST ignore client-identifier attributes that = are

      = directly supplied by source DOTS clients.  This implies that = first

      = server-side DOTS gateways MUST strip client-identifier = attributes

      = supplied by DOTS clients.

[Jon1] How do we = differentiate between an actual DOTS client and the client component of = a DOTS gateway (i.e. server-facing-side) as seen by a DOTS server?  = There is nothing that I have spotted for this in the DOTS signal = protocol.

 

[Med] I confirm, there = is no such text in the draft. A deployment would consist in explicitly = configuring a list of gateways (ACLs) on the server; the server will = trust client-id if and only if it is coming from a server-side gateways = in that list.

 <= /p>

[Jon2] Then do we need = to instruct the implementers of the signal channel that this is what = should be done?

[Med] What about = adding this text:

 

NEW: =

      = ;DOTS servers MAY support a

      = configuration parameter (e.g., ACLs) to identify DOTS = gateways

      = that are trusted to supply client-identifier = attributes.

[Jon4] I do not think = ACL is the right term here.  In the same way the a DOTS server = needs to know the valid client IDs of the DOTS clients that can use it = (along with the valid target IP addresses etc.) “valid = gateway” could be added in.  I would just drop “(e.g. = ACLS)”.

[Med] Dropped. =

 

[Jon1] I do agree that = true DOTS clients MUST NOT generate ‘client-identifiers’. If = only the DOTS gateway server component (client-facing-side) is allowed = to generate the client-identifier (for possible onward forwarding), this = gets around this issue as it is only the DOTS server component who is = allowed to do the generation.

 <= /p>

[Jon1] In my = implementation the DOTS server (gateway or not) always generates a = client-identifier (will be changed if there already is a unique = identifier following this discussion) which is associated with a = mitigation-id etc. so that the DOTS server can differentiate between the = same mitigation-id from different clients.

[Med] Ok, = thanks.

 

      = This is an optional attribute.

 

2nd change: Delete this text = because client-identifier is uniquely assigned by the first server-side = gateway; there is no need to prepend identifiers computed by other = gateways.

 

OLD:

   If the = 'client-identifier' value is already present in = the

   mitigation request = received from the DOTS client, the DOTS gateway

   MAY compute the = 'client-identifier' value, as discussed above, = and

   add the computed = 'client-identifier' value to the end of the = 'client-

   identifier' = list.

[Jon1] OK =

 

Comments and modifications are more welcome. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de mohamed.boucadair@orange.com=
Envoy=E9 : lundi 18 d=E9cembre 2017 = 13:28
=C0 : Jon Shallow; dots@ietf.org; kaname = nishizuka
Objet : Re: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 18 d=E9cembre 2017 = 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname = nishizuka
Objet : RE: [Dots] client-identifier: Recurisve = signaling & Aggregation

 

Hi Med / = Kaname,

 

“I = propose making it "MUST NOT":
The client-identifier attribute MUST NOT = be
      generated and included by the DOTS = client.”

We do need to handle the case of a broken client = (how does the DOTS server know it is a DOTS gateway client or a real = DOTS client?) who does not obey the MUST.

[Med] …but broken clients may = communicate directly with servers without any gateway on the path. =

 

“The = client-identifier attribute SHOULD NOT be generated and included by the = DOTS client. If a client-identifier was generated by the DOTS client, = the DOTS gateway MUST update the value with zero probability of the same = value among different DOTS clients.”

 

Is the safer option for = me.

 

[Med] Actually,

=B7         = (R1) we do need MUST so that as a general rule = clients do not insert a client-id parameter in their requests. =

=B7         = And (R2) DOTS servers MUST ignore client-ids = that are supplied by the origin DOTS clients.

 

In deployments without gateways, client-ids = supplied by broken DOTS clients will be ignored by the server as per R2. =

In deployments with gateways, the first = server-side gateway will follow R2 and strip any value supplied by the = client.

 

If we add text to cover (R2), I don’t = think we need a sentence about updating the content because client-id is = a value that is ***assigned*** exclusively by a dots = gateway:

 

      The = 'client-identifier' value MUST be assigned by the DOTS = gateway

      = ;            =             &= nbsp;     = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   =

      = ;in a manner that ensures that there is zero probability that = the

      = same value will be assigned to a different DOTS client.  =

 

Otherwise, see [Jon] inline (8 = times).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 18 December 2017 06:59
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Jon,

 

Thank you for sharing your thoughts. =

 

Please see comments = inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : samedi 16 d=E9cembre 2017 = 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi Med and all,

 

I think that = ‘gateway-identifier’ is likely to cause more confusion and = will not actually help to try and solve what I perceive is the = underlying issue that has triggered this discussion - “How do we = handle ‘client-identifiers’ when a DOTS gateway does = aggregation?”

[Med] There are also some complications even = when no aggregation is in use. See below.

 

.  I am leaning = towards your Option 2.  Some of my reasoning is = below.

 

Background to = client-identifiers.

 

In the general case = (e.g. no DOTS gateway aggregation of filters / aliases etc.), every time = a request or update (both signal and data) passes upstream through a = DOTS gateway, an additional ‘client-identifier’ is added to = the request / update.  The final DOTS server can then uniquely = identify the request / update as coming from a specific Client and = exactly match, say, an (possibly non unique alias-name) alias definition = sent over the data channel with a (possibly non unique mitigation-id) = mitigation request using the same alias-name sent over the signal = channel.

 

Client Identification = Usage Example

 

DOTS client (C1aj) = ------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS client (C1bj) = ----------------------------------------/     &n= bsp;           &nb= sp; =             &= nbsp;  |

       &nb= sp;           &nbs= p;            = ;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         |

DOTS client (C1ax) ----- (S1x) DOTS gateway = X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)    =

DOTS client (C1bx) = --------/          &nbs= p;            = ;        |    = ;            =             =    

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  |         &= nbsp;           &n= bsp;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway = Y (C2y) = -------/           = ;            =     =       

DOTS client (C1by) = --------/          &nbs= p;            = ;   =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Where CI is = ‘client-identifier’ – a unique hash of the client = identification :-

C1ax does a PUT = [alias-name=3DServer1],

C2x does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax)],=

C3k does a PUT = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and then = S3 uniquely stores this alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOTS forwarding = path will always be the same (that is, the same set of gateways will be = solicited for requests coming from a given DOTS = client).

 

[Jon] The current text = states “If the 'client-identifier' value is already present in = the

   = mitigation request received from the DOTS client, the DOTS = gateway

   = MAY compute the 'client-identifier' value, as discussed above, = and

   = add the computed 'client-identifier' value to the end of the = 'client-

   identifier' = list.”

 

[Jon]  The MAY is = not a MUST for the simple reason that if the original DOTS client = client-identifier is computed correctly, it should be unique all the way = through the different DOTS gateways (so no additional client-identifiers = need to get added) so that S3 just sees = [alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS = gateways in the path can then change over time with no = issues.

 

[Jon] All that is = required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients = behind gateways) and so does not need to add in additional = client-identifiers (but still adds in the first one if the first DOTS = gateway).

[Med] Agree for the first server-side gateway. =

 

[Jon] NOTE: A DOTS = gateway can elect to not add in any client-identifier – even if it = is the first in the chain if it wants to hide the client information, = but this will potentially cause information differentiation issues at = the DOTS server and I would not recommend it as client-identifiers, if = created properly, obfuscate the actual client information.

 

[Med]I do see some implications of this design in a = multi-homing scenario with the same mitigation provider: the same = request from a multi-homed DOTS client will be presented to the server = as being distinct requests…while this is not. It may be the same = request that is forked among existent network attachments or a request = that is sent over a first link, but a subsequent one over another = link.

 

[Jon] Perhaps I am = missing something here, but I would be expecting a multi-homed device to = be using the same PKI certificate (or equivalent) in which case the = client-identifier (which is not IP based) would be the same over the = different network interfaces. 

[Med] I’m referring to this = “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

 

[Jon] If however, the = different network interfaces are connected to different DOTS provider = domains, then there will be multiple PKI certs, and hence different = client-identifiers propagating up to the DOTS servers – but as = these are different provider domains will they ever join up into a = common domain?  If they do, then this is where you could be getting = conflicting requests – subject of another = discussion.

[Med] Sure, these are deployment-specific. My = concern is to avoid design choices that make hidden assumptions. =  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation). =    

 

[Jon] Yes – the = assumption being that all the client-identifiers are unique – In = which case I argue again that additional information – e.g. = gateway-identifiers are irrelevant (and also are useless when there are = multiple paths through the DOTS gateways as you refer to = above).

[Med] If we agree that one (unique) client-id = is supplied, then I’m fine.

 

so that if any of the = DOTS clients do a PUT [alias-name=3DServer1] (with same alias name) S3 = can differentiate them all based on the different = CI().

 

Then when C1ax requests = a mitigation with alias-name=3DServer1, by the time the request gets to = S3, S3 can match the alias-name definition in the mitigate request with = that of = [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)].

 

If C1aj also requests a = mitigation with alias-name=3DServer1, S3 will see the alias-name as = [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] and match = accordingly.

 

As responses come back = from S3 to the originating client, the appropriate CI(cxxx) gets = stripped off so the originating client sees no = ‘client-identifier’ fields at all.

 

This general solution is = simple with only one disadvantage – there is a limit of 20 - 24 = client-identifiers (20 – 24 DOTS gateways) that will fit into a = single UDP packet due to MTU restrictions.  However in practice = there are unlikely to be this number of DOTS gateways.  The count = varies based on how much other information needs to be put into the = packet.

 

DOTS Gateway Session = aggregation

 

There is no reason as to = why multiple DOTS clients’ signal and data requests cannot be = multiplexed into a single session on the DOTS gateway to DOTS server = connection – especially as different client-identifiers separate = out the different requests / responses.

 

This session aggregation = is not the same as signal / data aggregation

 

NOTE: = ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which = may be where some of the confusion comes in)

Figure 7: Client-Side = Gateway with session Aggregation

Figure 8: Client-Side = Gateway without session Aggregation

Figure 9: Server-Side = Gateway with session Aggregation

Figure 10: Server-Side = Gateway without session Aggregation

 

[Med] Agree.

 

DOTS Gateway signal / = data aggregation challenges

 

Individual clients in = general will generate their unique mitigation requests – but may = have common information (e.g. same protocol, ports, alias-name).  = If the mitigation requests are not unique then we have potential = conflicts – not part of this discussion.

 

Aggregating (unique) = mitigation requests on a DOTS gateway could be a programmatic challenge, = unless it is the simple aggregation of all the different target-prefixes = – aggregating different port requirements for different = target-prefixes gets more interesting…..  This adds in a lot = of potential complexity with potential for boundary condition error = issues.

 

Aggregation of Filters = is at first sight relatively simple - but there then may be ordering = challenges / conflicts – e.g. one filter has an IP that is a = white-list, and another has the same IP as a black-list – both = valid in the respective client environment.  Ordering of = conflicting filter information is important  and I am not sure that = a DOTS gateway will do this properly unless it either has some hints or = complex rules to work with – just adding in complexity where more = things can potentially go wrong.

 

Use of = gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of = client-identifiers that are allowed to use this aggregated filter rule), = but again we are limited to 20 – 24 *-identifiers in total due to = packet MTU.  Even if we for example say that there is a maximum of = 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the = number of supported DOTS clients per DOTS gateway if aggregation is = supported?

 

[Med] I guess you meant “restrict the = number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would = say this is deployment-specific. A deployment that enables signal/data = channel aggregation is aware of this limitation. =

 

[Jon] Yes, that is = better phrasing.

[Med] OK.

 

  I still struggle = with how do you actually do the aggregation (merging of data/signal) at = any gateway other than in a couple of simple cases out of the many = different scenarios.

[Med] Please note that I used = “good/bad = deployment choices” in the initial message. Merging the = requests will induce some complexity at the gateway, sure. From a = protocol standpoint, I’m trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have = deployment implications.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: = [Dots] client-identifier: Recurisve signaling & = Aggregation

 

Hi all,

 

To avoid potential conflicts and also in order to help the = server select the appropriate policy to enforce, signal/data channel = protocol drafts specify a parameter called = “client-identifier”. The design allows this parameter to = carry multiple values.

 

Putting aside the extensibility argument of the data = model, the signal/data channel protocol drafts are silent about the = exact use of multiple values.

 

The potential deployment cases for multiple values are = (without making any assumption whether these cases are good/bad = deployment choices):

 

(1)Multiple = gateways may be on path. For example, draft-ietf-dots-architecture = discusses recursive signaling and also cases where multiple DOTS = gateways are involved.

(2)Requests = from multiple clients may be aggregated by the same server-side into one = single request forwarded to the upstream server. For example, filtering = rules received from multiple clients of the same domain may be = aggregated in one single request.   

 

The current approach has the merit to not make any = assumption on the gateway behavior (e.g., (2)), but it leads to a = confusion. For example, a DOTS server does not know whether multiple = client-ids supplied in a messages refer to multiple DOTS clients or to a = DOTS client and a set of on-path gateways. The protocol documents need = to be updated to avoid such confusion. Two options are listed below: =

 

Option 1 (Avoid making any assumption on gateways/proper = semantic distinction between clients and on-path = gateways)

-    Restrict the usage of ‘client-identifier’ to = carry identifiers of clients, not gateways.

-    On-path gateways may include a new parameter called = ‘gateway-identifier’ to ease contexts retrieval and avoid = potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘gateway-identifier’ pointing to = G1

 

Option 2 (Describe what a gateway cannot = do)

-    Update the architecture document to indicate that requests = are not aggregated by a dots gateway.

-    ‘client-identifier’ includes multiple values = only and only if multiple gateways are on-path. The order of the values = is important because the first one will be the one pointing to the = source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with = ‘client-identifier’ pointing to C

G2 will = update the request with ‘client-identifier’ pointing to G1 = (in addition to C)

 

We are seeking for feedback from the WG on which direction = to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

------=_NextPart_000_0370_01D378AF.AA8EC6D0-- From nobody Tue Dec 19 02:02:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C802112D96B for ; Tue, 19 Dec 2017 02:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y2GFM-IuewR for ; Tue, 19 Dec 2017 02:01:59 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518EF12778E for ; Tue, 19 Dec 2017 02:01:59 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id A60F940544; Tue, 19 Dec 2017 11:01:57 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 857B91A0091; Tue, 19 Dec 2017 11:01:57 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 11:01:56 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel Heartbeats Thread-Index: AdN4ENbheXtf5t9VRkK1cf1kUKfP+AAitvLA Date: Tue, 19 Dec 2017 10:01:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> In-Reply-To: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09AA66OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:02:03 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09AA66OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Thank you for initiating this thread. This is exactly the discussion I want= ed to have. The initial requirement that motivated introducing config-interval was the = following from the requirements I-D: When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Also, given that configuration changes may occur at the server, clients wil= l continue using stale configuration data retrieved previously from the ser= ver because there is no procedure to refresh the config. This is undesirabl= e. config-interval solves this. Of course, DOTS agents may decide to disabl= e the refresh procedure by setting it to 0 or by not returning the paramete= r. Having distinct heartbeat values (peacetime/attack) is an option, but it do= es not address the issue of stale configuration. Note that, for example, a = distinct max-retransmit may also be configured for peace time. The following would meet all the requirements: +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 =B7 If no peace-time-config is provided, the same values will be us= ed for both peace and attack times till a change occurs. This is what is cu= rrently in the draft. =B7 peace-time-config may be returned to specify values to be used = for peacetime. Switching between attack/peace time parameter values will be= automatic. Your point (A) makes sense to me. What about adding the following: NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. I do fully agree that consistent setting of the parameters is important. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats Hi there, There has been a lot of discussion on this, culminating in an update in dra= ft-ietf-dots-signal-channel-13 where 'config-interval' has been added in to= try to handle the different concerns. >From my trying to simplify things perspective:- 1. NAT devices usually allow outbound session requests (source IP nat'ing) = and allow for a response to come back within a defined time frame (lots of = discussion on this time frame - eventually setting on 30 seconds as a good = compromise - but could be longer). 2. NAT devices may be configured to allow inbound session requests (port re= direction) and allow for a response to come back within a defined time fram= e. Doing this does raise security policy issues as this potentially allows= uncontrolled access from the Internet to an internal device. 3. NAT devices are likely to break any server initiated heartbeats if the s= erver request frequency is longer than a NAT session is maintained in the N= AT device, and inbound session requests are disabled (for security reasons)= . 4. The frequency of Heartbeats ideally are different between peace time and= attack. In peace time there could be no heartbeats or at a slow rate to k= eep the signal channel alive. In attack time, 30 seconds appears to be the= agreed compromise time, but this is also influenced by the underlying COAP= protocol (retry intervals and counters etc.). In attack time, the rate s= hould be sufficient to detect any transmission issues within a reasonable t= ime frame. 5. For DOTS clients, there should be no issues with heartbeats going throug= h NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. 6. For DOTS servers dropping the heartbeat rate below that of the active NA= T session time will cause issues if there is a NAT device that does not all= ow inbound initiated sessions. 7. If heartbeats are in use, then both DOTS server and DOTS client have to = do their separate heartbeats for network connectively / DOTS agent availabi= lity. 8. If heartbeats are being used, the DOTS server can optionally trigger mit= igation is heartbeats stop working To give the ability to change the heartbeat rates, 'config-interval' has be= en added to the signal draft. A client then knows when to re-request the c= onfiguration (e.g. for potentially changed heartbeat values). However, 'co= nfig-interval' has to be sufficiently large to not compete with the heartbe= at rate (if they both were for the same interval, then configuration update= requests would effectively be doing the same task as heartbeats!). But if= 'config-interval' is too large (signal draft-13 example has it as 24 minut= es) then it could take time for the heartbeat rate to get increased in atta= ck time (and if the config update response packet does not get through, it = will not get updated). I think 'config-interval' needs to be thought throu= gh further. I have 2 proposals here A. If the heartbeat frequency is below that of the NAT session inactive tim= eout, the DOTS client will always transmit the heartbeats at the appropriat= e frequency. When the heartbeat request arrives at the DOTS server, this t= riggers a heartbeat process on the DOTS server to then heartbeat test the D= OTS client. Thus the DOTS server can use the "warm" NAT session during pea= cetime. If the heartbeat requests do not come in from the DOTS client (and= a peacetime heartbeat rate is configured) then auto-mitigation can get inv= oked if required. B. There are defined two heartbeat rates - one for when one or more mitigat= ion requests are in progress (attack situations) and a second rate for peac= e time (can be 0 (no heartbeats) or some long timeout). Whenever the first= mitigation is requested over a DOTS session, both ends start heart-beating= at the "attack" rate. This gets rid of any potential 'config-interval' r= efresh delays / 'new heartbeat interval' packets getting lost. When there = are no more mitigations active for that DOTS session, then the DOTS session= drops immediately back into the peacetime values. 'config-interval' could= then be replaced with 'peace-time-heartbeat-interval'. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A09AA66OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thank you for initiating this t= hread. This is exactly the discussion I wanted to have.

 

The initial requirement that mo= tivated introducing config-interval was the following from the requirements= I-D:

 

   &= nbsp;  When DOTS agents are exchanging heartbeats and no

   &= nbsp;  mitigation request is active, either agent MAY request changes = to

   &= nbsp;  the heartbeat rate.  For example, a DOTS server might want= to

   &= nbsp;  reduce heartbeat frequency or cease heartbeat exchanges when an=

   &= nbsp;  active DOTS client has not requested mitigation, in order to

   &= nbsp;  control load.

 

Also, given that configuration = changes may occur at the server, clients will continue using stale configur= ation data retrieved previously from the server because there is no procedure to refresh the config. This is undesirable. = config-interval solves this. Of course, DOTS agents may decide to disable t= he refresh procedure by setting it to 0 or by not returning the parameter.

 

Having distinct heartbeat value= s (peacetime/attack) is an option, but it does not address the issue of sta= le configuration. Note that, for example, a distinct max-retransmit may also be configured for peace time.

 

The following would meet all th= e requirements:  

 

        &=
nbsp; +--:(configuration)
        &=
nbsp;    +--rw session-id     &=
nbsp;      int32
        &=
nbsp;    +--rw heartbeat-interval?   int16
        &=
nbsp;    +--rw missing-hb-allowed?   int16
        &=
nbsp;    +--rw max-retransmit?    &n=
bsp;  int16
        &=
nbsp;    +--rw ack-timeout?     =
;     int16
        &=
nbsp;    +--rw ack-random-factor?    deci=
mal64
        &=
nbsp;    +--rw trigger-mitigation?   Boolean
        &=
nbsp;    +--rw peace-time-config
         =
    |   +--rw heartbeat-interval? &n=
bsp; int16
         =
    |   +--rw missing-hb-allowed? &n=
bsp; int16
         =
    |   +--rw max-retransmit?  =
     int16
        &=
nbsp;    |   +--rw ack-timeout?  &nb=
sp;       int16
        &=
nbsp;    |   +--rw ack-random-factor? &nb=
sp;  decimal64
        &=
nbsp;    +--rw config-interval?    &=
nbsp; int32

 

=B7    &n= bsp;    If no peace-time-config= is provided, the same values will be used for both peace and attack times = till a change occurs. This is what is currently in the draft.

=B7    &n= bsp;    peace-time-config may b= e returned to specify values to be used for peacetime. Switching between at= tack/peace time parameter values will be automatic.

 

Your point (A) makes sense to m= e. What about adding the following:

 

NEW:

   In order to avoid complications due =
to the presence of some stateful
   translators and firewalls (e.g., dis=
card an incoming packet because
   no matching state is found), DOTS se=
rvers MAY trigger their heartbeat
   requests immediately after receiving=
 heartbeat probes from peer DOTS
   clients.

 

I do fully agree that consisten= t setting of the parameters is important.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : lundi 18 d=E9cembre 2017 16:00
=C0 : dots@ietf.org
Objet : [Dots] Signal Channel Heartbeats

 

Hi there,

 

There has been a lot of discuss= ion on this, culminating in an update in draft-ietf-dots-signal-channel-13 = where ‘config-interval’ has been added in to try to handle the = different concerns.

 

From my trying to simplify thin= gs perspective:-

 

1. NAT devices usually allow ou= tbound session requests (source IP nat’ing) and allow for a response = to come back within a defined time frame (lots of discussion on this time f= rame – eventually setting on 30 seconds as a good compromise – but could be longer).

 

2. NAT devices may be configure= d to allow inbound session requests (port redirection) and allow for a resp= onse to come back within a defined time frame.  Doing this does raise = security policy issues as this potentially allows uncontrolled access from the Internet to an internal device.

 

3. NAT devices are likely to br= eak any server initiated heartbeats if the server request frequency is long= er than a NAT session is maintained in the NAT device, and inbound session = requests are disabled (for security reasons).

 

4. The frequency of Heartbeats = ideally are different between peace time and attack.  In peace time th= ere could be no heartbeats or at a slow rate to keep the signal channel ali= ve.  In attack time, 30 seconds appears to be the agreed compromise time, but this is also influenced by the underlyi= ng COAP protocol  (retry intervals and counters etc.).  In attack= time, the rate should be sufficient to detect any transmission issues with= in a reasonable time frame.

 

5. For DOTS clients, there shou= ld be no issues with heartbeats going through NAT devices (other than durin= g an attack where there may be packet loss) no matter what the heartbeat fr= equency is.

 

6. For DOTS servers dropping th= e heartbeat rate below that of the active NAT session time will cause issue= s if there is a NAT device that does not allow inbound initiated sessions.<= o:p>

 

7. If heartbeats are in use, th= en both DOTS server and DOTS client have to do their separate heartbeats fo= r network connectively / DOTS agent availability.

 

8. If heartbeats are being used= , the DOTS server can optionally trigger mitigation is heartbeats stop work= ing

 

To give the ability to change t= he heartbeat rates, ‘config-interval’ has been added to the sig= nal draft.  A client then knows when to re-request the configuration (= e.g. for potentially changed heartbeat values).  However, ‘config-interval’ has to be sufficiently large to not compete = with the heartbeat rate (if they both were for the same interval, then conf= iguration update requests would effectively be doing the same task as heart= beats!).  But if ‘config-interval’ is too large (signal draft-13 example has it as 24 minutes) then it could take time for= the heartbeat rate to get increased in attack time (and if the config upda= te response packet does not get through, it will not get updated).  I = think ‘config-interval’ needs to be thought through further.

 

I have 2 proposals here

 

A. If the heartbeat frequency i= s below that of the NAT session inactive timeout, the DOTS client will alwa= ys transmit the heartbeats at the appropriate frequency.  When the hea= rtbeat request arrives at the DOTS server, this triggers a heartbeat process on the DOTS server to then heartbeat tes= t the DOTS client.  Thus the DOTS server can use the “warm”= ; NAT session during peacetime.  If the heartbeat requests do not come= in from the DOTS client (and a peacetime heartbeat rate is configured) then auto-mitigation can get invoked if required.

 

B. There are defined two heartb= eat rates – one for when one or more mitigation requests are in progr= ess (attack situations) and a second rate for peace time (can be 0 (no hear= tbeats) or some long timeout).  Whenever the first mitigation is requested over a DOTS session, both ends start heart-b= eating at the “attack” rate.   This gets rid of any p= otential ‘config-interval’ refresh delays / ‘new heartbea= t interval’ packets getting lost.  When there are no more mitiga= tions active for that DOTS session, then the DOTS session drops immediately back into t= he peacetime values.  ‘config-interval’ could then be repl= aced with ‘peace-time-heartbeat-interval’.

 

Regards

 

Jon

 

 

--_000_787AE7BB302AE849A7480A190F8B93300A09AA66OPEXCLILMA3corp_-- From nobody Tue Dec 19 02:15:47 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32581276AF for ; Tue, 19 Dec 2017 02:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXDsKqECY_fl for ; Tue, 19 Dec 2017 02:15:44 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D91A126B71 for ; Tue, 19 Dec 2017 02:15:44 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id E1496180C2E; Tue, 19 Dec 2017 11:15:42 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id C3FC01C0087; Tue, 19 Dec 2017 11:15:42 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 11:15:42 +0100 From: To: Roman Danyliw , "dots@ietf.org" Thread-Topic: WGLC on DOTS Requirements Thread-Index: AdNvm/lDz0QLqz1aR/uWENfjoLPoNQJFQ1UQ Date: Tue, 19 Dec 2017 10:15:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09AA83@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:15:46 -0000 Re-, I'm extracting this comment from Jon to be handled as part of the WGLC comm= ents: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jon said:=20 To prevent others getting confused, my suggestion would be to update the fo= llowing in the various draft specs "Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway" "Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway" "DOTS gateway server-side" to "DOTS gateway server-facing-side" "DOTS gateway client-side" to "DOTS gateway client-facing-side" The latter 2 should be defined somewhere. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please refer to: https://www.ietf.org/mail-archive/web/dots/current/msg0176= 5.html. I like the initial wording, but it seems this is not clear enough and may l= ead to confusion.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw > Envoy=E9=A0: jeudi 7 d=E9cembre 2017 21:51 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the Singapore meeting and with the > concurrence of the draft authors, we are starting a working group last > call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >=20 > Please send all comments to the DOTS mailing list. >=20 > This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the= - > calendar year vacations). >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 02:21:59 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78659127599 for ; Tue, 19 Dec 2017 02:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63TOAt6gOaa9 for ; Tue, 19 Dec 2017 02:21:53 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBF9126B71 for ; Tue, 19 Dec 2017 02:21:52 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 2B5531205F0; Tue, 19 Dec 2017 11:21:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id EFD1860085; Tue, 19 Dec 2017 11:21:50 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 11:21:50 +0100 From: To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7VkBqcCOJgIawgPMAiQ/gFoBwIP+EAMzYTETAkWEwxEDVu2BwAILYvd7Ajb4MCQBNYeI1QJ2o5bloBAowxCg83QCIA== Date: Tue, 19 Dec 2017 10:21:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09AA97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <031001d3781d$55f34f70$01d9ee50$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A920@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <036f01d378af$aa8550f0$ff8ff2d0$@jpshallow.com> In-Reply-To: <036f01d378af$aa8550f0$ff8ff2d0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09AA97OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:21:57 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09AA97OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 19 d=E9cembre 2017 10:57 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, "[Med] I suspect the disconnect is caused by mixing connectivity and DOTS c= ontrol aspects" Ahh - the light bulb has gone off - why our discussions had a disconnect. = It is down to the interpretation of the word "side" as used in "Client Side= DOTS gateway". To you it meant "control or ownership", to me "connectivit= y or position relative to DOTS gateway". [Med] Yes, indeed. To prevent others getting confused, my suggestion would be to update the fo= llowing in the various draft specs "Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway" "Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway" "DOTS gateway server-side" to "DOTS gateway server-facing-side" "DOTS gateway client-side" to "DOTS gateway client-facing-side" The latter 2 should be defined somewhere. [Med] I extracted this comment and sent it as a comment to the ongoing WGLC= on the requirements I-D. The signal channel/data channel drafts will be up= dated to reflect whatever change will be endorsed in the requirements I-D. To me, a gateway is a border of some sort - where there is a potential disc= ontinuity of flow (e.g. aggregation, client/server etc.) Otherwise, see inline [Jon5]. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 07:15 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 17:29 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, See inline [Jon4]. I have deleted some of the "see inline messages". Regards Jon De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, Going in the right direction, but see comments inline [Jon1]. As a side comment, I always have to think twice what "DOTS gateway server-s= ide" actually means. It actually means the DOTS client component logic of = a DOTS gateway. There is no definition of terms in the signal channel draf= t, but the definition could perhaps be added to the dots requirements draft= . Others may also get confused about this. Perhaps "DOTS gateway server-f= acing-side" is clearer, even though much longer to type! [Med] We do have the following definition in the requirements I-D: Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. [Jon2] Yes - actually, this adds to the confusion in my mind. For a singul= ar DOTS gateway, it could have a client-facing-side that is in the DOTS cli= ent domain, and a server-facing side that is in a different DOTS server dom= ain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for th= e "client-facing side" of a gateway to belong to the client domain and its = "server-facing side" to belong to the server domain? [Jon3]The recursive gateway comes immediately to mind - when an ISP cannot = handle the current attack and wants to invoke someone else to handle it. O= therwise to me, a gateway to me is either an aggregation point of clients w= ithin a common domain or a border between two different domains. [Med] Given that recursive signalling is opaque to the origin DOTS client, = all involved gateways are IMHO at the server-side (from the perspective of = the source client). The only difference is that the intermediate dots gatew= ay (server) is managed by Provider 1 while the final server is managed by a= nother provider. [Jon4] Hmm - I am not convinced. Some of your examples below actually give= examples for a DOTS gateway sitting in both client and (different) server = domains. [Med] I suspect the disconnect is caused by mixing connectivity and DOTS co= ntrol aspects. [Jon5] Thanks - this is the cause of our disconnect in interpretation of "s= ide" - well spotted [Jon2] Also, being picky, does "Client-side DOTS gateway" (type of DOTS gat= eway) actually mean the same as "DOTS gateway client-side" (component withi= n a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - "xxx-side DOTS gateway" means this is owned and operated by xxx. - "DOTS gateway client-side" refers to the client-facing interface of a = DTOS gateway. It applies for both client- and server-side getaways. [Jon3] I agree with your distinct definitions, but not the use of the defin= ition in the requirements I-D to cover the definition of "DOTS Gateway clie= nt-side" Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway are= separate (the server-facing component has no real knowledge of what is hap= pening on the client-facing side), it needs to be the client-facing-side of= the DOTS gateway that assigns the (unique) client-identifier which is then= passed over to the server-facing-side for onward transmission. [Med] You are right if we zoom on the internal implementation of a DOTS gat= eway. This part of the text focuses on the external behavior of the DOTS ga= teway. The text does not need to zoom in given that the second sentence abo= ve says; [Jon2] In terms of helping the implementers, the use of only DOTS server be= ing allowed to generate a 'client-identifier' as discussed later. If "serv= er-side" was removed as in :- "client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity ..." Removes a lot of confusion in my mind. [Med] The "server-side" is important because we don't want client-side GWs = to reveal the identity of internal dots clients. [Jon3] Why do we need to be restrictive to "Server-side DOTS gateways" here= ? [Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients ar= e deployed in the client's domain. [Jon4] But all this (deployment etc.) information is in the client domain o= nly using your definition of a client-side DOTS gateway - so within the cli= ent space who the really cares? [Jon4] But this information going into another domain is the security conce= rn. However, to get a mitigation request to go between domains, there has = to be a border at some point. How do we handle that? What does the border= look like (it cannot be a client-side or server-side DOTS gateway as that = is not allowed to straddle domains as you assert)? [Med] It looks like what is described in the architecture draft: a gateway = located in the server-side. example.net domain . . . . . . . . . . . . . . . . . . Gn . +----+ 1 . +----+ +-----------+ . | Cc |<--------->| Sn |~~~~~~~| Mitigator | . +----+ . +=3D=3D=3D=3D+ | Mn | . . | Cn | +-----------+ . example.com . +----+ . client . ^ . . . .|. . . . . . . . . . . . . . | 1 | | . . .|. . . . . . . . . . . . . . . v . . +----+ +-----------+ . . | So |~~~~~~~| Mitigator | . . +----+ | Mo | . . +-----------+ . . . . . . . . . . . . . . . . . . . . example.org domain Figure 13: Recursive Signaling [Jon5] Note: It is possible that Cc actually is a gateway - which would be = client managed and is the border point [Med] Yes, Cc may a be "client-side DOTS gateway" or "Client Domain Managed= DOTS gateway" if you will :) We do have this text (that may be tweaked): In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. [Jon4] I had always read this as being a DOTS gateway on the border of a di= fferent client and server domain [Med] The mention which is important in that text is: "DOTS gateways locate= d in the client-domain". [Jon5] Agreed. However, if there are multiple gateways in the chain, all c= lient managed, it is only the one on the border with a server domain that n= eeds to be extra careful. [Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client= -identifiers" (which are obfuscated to hide identity). If they do not pass= on "client-identifiers" then the DOTS server they connect to (which is in = the same domain by definition) will not be able to differentiate between th= e different clients - the whole purpose of "client-identifiers" - or am I m= issing something here? [Med] For client-side DOTS gateways, the server does not need to rely upon = the identity of internal DOTS clients; the identity of the gw is sufficient= . Imagine an enterprise network with multiple DOTS clients and a DOTS gatew= ay located on the CPE that intercepts all messages from these clients. The = ultimate DOTS server does not to know about those DOTS clients. [Jon4] Again an example of a DOTS gateway that sits both in a client and (d= ifferent) server domain. [Med] The CPE is in the border from a connectivity standpoint, but for DOTS= , the gateway is under the control of the client. I don't see the "server d= omain" part in this example. [Jon5] Again a disconnect in our interpretation, now understood. To me the= gateway (albeit it client managed) is the border between the client and se= rver domains. [Med] Let's fix the wording to avoid confusion. [Jon3] To me, the only time that "client-identifiers" may need to be droppe= d (not that I recommend doing this) is when a DOTS Gateway is sitting in bo= th a client's domain and a different server's domain as a domain border gat= eway. "to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. " DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer "a list of 'client-identifier' values; each value is pointi= ng to a unique DOTS client that is in the aggregated list. It is out of...." [Med] Deal. aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the client= component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS se= rver? There is nothing that I have spotted for this in the DOTS signal pro= tocol. [Med] I confirm, there is no such text in the draft. A deployment would con= sist in explicitly configuring a list of gateways (ACLs) on the server; the= server will trust client-id if and only if it is coming from a server-side= gateways in that list. [Jon2] Then do we need to instruct the implementers of the signal channel t= hat this is what should be done? [Med] What about adding this text: NEW: DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon4] I do not think ACL is the right term here. In the same way the a DO= TS server needs to know the valid client IDs of the DOTS clients that can u= se it (along with the valid target IP addresses etc.) "valid gateway" could= be added in. I would just drop "(e.g. ACLS)". [Med] Dropped. [Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifi= ers'. If only the DOTS gateway server component (client-facing-side) is all= owed to generate the client-identifier (for possible onward forwarding), th= is gets around this issue as it is only the DOTS server component who is al= lowed to do the generation. [Jon1] In my implementation the DOTS server (gateway or not) always generat= es a client-identifier (will be changed if there already is a unique identi= fier following this discussion) which is associated with a mitigation-id et= c. so that the DOTS server can differentiate between the same mitigation-id= from different clients. [Med] Ok, thanks. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09AA97OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 19 d=E9cembre 2017 10:57
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuk= a
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

“= [Med] I suspect the disconnect is caused by mix= ing connectivity and DOTS control aspects”

&nbs= p;

Ahh ̵= 1; the light bulb has gone off – why our discussions had a disconnect= .  It is down to the interpretation of the word “side” as = used in “Client Side DOTS gateway”.  To you it meant ̶= 0;control or ownership”, to me “connectivity or position relative to DOTS gateway”.

[Med] Yes, indeed.

 

&nbs= p;

To preven= t others getting confused, my suggestion would be to update the following i= n the various draft specs

&nbs= p;

“Cl= ient-Side DOTS Gateway” to “Client Domain Managed DOTS gateway&= #8221;

“Se= rver-Side DOTS Gateway” to “Server Domain Managed DOTS gateway&= #8221;

“DO= TS gateway server-side” to “DOTS gateway server-facing-sideR= 21;

“DO= TS gateway client-side” to “DOTS gateway client-facing-sideR= 21;

&nbs= p;

The latte= r 2 should be defined somewhere.

 

[Med] I extracted this comment = and sent it as a comment to the ongoing WGLC on the requirements I-D. The s= ignal channel/data channel drafts will be updated to reflect whatever change will be endorsed in the requirements I-D.<= /o:p>

&nbs= p;

To me, a = gateway is a border of some sort – where there is a potential discont= inuity of flow (e.g. aggregation, client/server etc.)

&nbs= p;

Otherwise= , see inline [Jon5].

&nbs= p;

Regards

&nbs= p;

Jon<= /o:p>

&n= bsp;

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 19 December 2017 07:15
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 17:29
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

See inl= ine [Jon4].  I have deleted some of the “see inline messagesR= 21;.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

Going i= n the right direction, but see comments inline [Jon1].

&n= bsp;

As a si= de comment, I always have to think twice what “DOTS gateway server-si= de” actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definiti= on of terms in the signal channel draft, but the definition could perhaps b= e added to the dots requirements draft.  Others may also get confused = about this.  Perhaps “DOTS gateway server-facing-side” is clearer, even though much longer to type!

 

[Med] We do have the following = definition in the requirements I-D:

 

   &= nbsp;  Client-side DOTS gateways

   &= nbsp;  are DOTS gateways that are in the DOTS client's domain, while

   &= nbsp;  server-side DOTS gateways denote DOTS gateways that are in the<= o:p>

   &= nbsp;  DOTS server's domain.

&n= bsp;

&n= bsp;

[Jon2] = Yes – actually, this adds to the confusion in my mind.  For a si= ngular DOTS gateway, it could have a client-facing-side that is in the DOTS= client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one= or the other, but not both.

[Med] Do you have a particular = case in mind in which we should allow for the “client-facing sideR= 21; of a gateway to belong to the client domain and its “server-facin= g side” to belong to the server domain?

[Jon3]T= he recursive gateway comes immediately to mind – when an ISP cannot h= andle the current attack and wants to invoke someone else to handle it.&nbs= p; Otherwise to me, a gateway to me is either an aggregation point of clients within a common domain or a border between tw= o different domains.

[Med] Given that recursive sign= alling is opaque to the origin DOTS client, all involved gateways are IMHO = at the server-side (from the perspective of the source client). The only difference is that the intermediate dots gateway = (server) is managed by Provider 1 while the final server is managed by anot= her provider.

[Jon4] = Hmm – I am not convinced.  Some of your examples below actually = give examples for a DOTS gateway sitting in both client and (different) ser= ver domains.

[Med] I suspect the disconnect = is caused by mixing connectivity and DOTS control aspects.

[Jon5] = Thanks – this is the cause of our disconnect in interpretation of = 220;side” – well spotted

 

&n= bsp;

[Jon2] = Also, being picky, does “Client-side DOTS gateway” (type of DOT= S gateway) actually mean the same as “DOTS gateway client-side”= (component within a DOTS gateway)?

[Med] No. Those are two distinc= t things/dimensions:

-  = ;  “xxx-side DOTS ga= teway” means this is owned and operated by xxx.

-  = ;  “DOTS gateway cli= ent-side” refers to the client-facing interface of a DTOS gateway. It= applies for both client- and server-side getaways.  

[Jon3] = I agree with your distinct definitions, but not the use of the definition i= n the requirements I-D to cover the definition of “DOTS Gateway clien= t-side”

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 13:04
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Jon,

 

Please see below two proposed c= hanges to hopefully conclude on the issues discussed in this thread:

 

1st change:

 

OLD:

   client= -identifier:  The client identifier MAY be conveyed by the DOTS

   &= nbsp;  gateway to propagate the DOTS client identity from the gateway'= s

   &= nbsp;  client-side to the gateway's server-side, and from the gateway'= s

   &= nbsp;  server-side to the DOTS server.  This allows the DOTS serv= er to

   &= nbsp;  accept mitigation requests with scopes which the DOTS client is=

   &= nbsp; authorized to manage.

 

   &= nbsp;  The 'client-identifier' value MUST be assigned by the DOTS gate= way

   &= nbsp;  in a manner that ensures that there is zero probability that th= e

   &= nbsp;  same value will be assigned to a different DOTS client.  T= he DOTS

   &= nbsp;  gateway MUST conceal potentially sensitive DOTS client identity=

   &= nbsp;  information.  The client-identifier attribute SHOULD NOT b= e

   &= nbsp;  generated and included by the DOTS client.

 

   &= nbsp;  This is an optional attribute.

 

NEW:

   client= -identifier:  The client identifier MAY be conveyed by a

   &= nbsp;  server-side DOTS gateway to propagate the DOTS client identity<= o:p>

   &= nbsp;  from the gateway's client-side to the gateway's server-side, an= d

   &= nbsp;  from the gateway's server-side to the DOTS server. 'client-

   &= nbsp;  identifier' MAY be used by the final DOTS server for policy

   &= nbsp;  enforcement purposes.

 

   &= nbsp;  The 'client-identifier' value MUST be assigned by the server-si= de

[Jon1]  Actually, as the client and server components= of a DOTs gateway are separate (the server-facing component has no real kn= owledge of what is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assi= gns the (unique) client-identifier which is then passed over to the server-= facing-side for onward transmission.

&n= bsp;

[Med] Y= ou are right if we zoom on the internal implementation of a DOTS gateway. T= his part of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that the seco= nd sentence above says;

 

[Jon2] In terms of helping the implementers, the use of on= ly DOTS server being allowed to generate a ‘client-identifier’ = as discussed later.  If “server-side” was removed as in :-

“client-identifier:&nbs= p; The client identifier MAY be conveyed by a

      DOTS gateway to propagate t= he DOTS client identity …”

Removes a lot of confusion in my mind.

&n= bsp;

[Med] T= he “server-side” is important because we don’t want clien= t-side GWs to reveal the identity of internal dots clients.

[Jon3] Why do we need to be restrictive to “Server-s= ide DOTS gateways” here?

[Med] F= or privacy concerns: e.g., avoid revealing how/where DOTS clients are deplo= yed in the client’s domain.

[Jon4] But all this (deployment etc.) information is in th= e client domain only using your definition of a client-side DOTS gateway &#= 8211; so within the client space who the really cares?

[Jon4] But this information going into another domain is t= he security concern.  However, to get a mitigation request to go betwe= en domains, there has to be a border at some point.  How do we handle that?  What does the border look like (= it cannot be a client-side or server-side DOTS gateway as that is not allow= ed to straddle domains as you assert)?

[Med] I= t looks like what is described in the architecture draft: a gateway located= in the server-side.

 <= o:p>

   &= nbsp;           &nbs= p;        example.net domain<= /span>

   &= nbsp;           &nbs= p;        . . . . . . . . . . . . . . . = . .

   &= nbsp;           &nbs= p;        .    Gn &n= bsp;            = ;           .<= /span>

   &= nbsp;      +----+    1 = ;  .  +----+       +---= --------+   .

   &= nbsp;      | Cc |<--------->| Sn |~~~~~~~| M= itigator |   .

   &= nbsp;      +----+    &= nbsp;   .  +=3D=3D=3D=3D+    &nb= sp;  |     Mn    |   .

   &= nbsp;           &nbs= p;        .  | Cn |  &nbs= p;    +-----------+   .<= /p>

   &= nbsp;    example.com     .  +--= --+           &n= bsp;           .

   &= nbsp;       client    &nb= sp;  .    ^       &n= bsp;            &nbs= p;     .

   &= nbsp;           &nbs= p;        . . .|. . . . . . . . . . . . = . .

   &= nbsp;           &nbs= p;             = |

   &= nbsp;           &nbs= p;           1 |

   &= nbsp;           &nbs= p;             = |

   &= nbsp;           &nbs= p;        . . .|. . . . . . . . . . . . = . .

   &= nbsp;           &nbs= p;        .    v &nb= sp;            =             .

   &= nbsp;           &nbs= p;        .  +----+ &n= bsp;     +-----------+   .=

   &= nbsp;           &nbs= p;        .  | So |~~~~~~~| Mitigat= or |   .

   &= nbsp;           &nbs= p;        .  +----+    &nbs= p;  |     Mo    |   .

     &nbs= p;            &= nbsp;     .       &n= bsp;       +-----------+   = .

     &nbs= p;            &= nbsp;     .       &n= bsp;            = ;           .<= /span>

     &nbs= p;            &= nbsp;     . . . . . . . . . . . . . . . . .<= /span>

     &nbs= p;            &= nbsp;     example.org domain

 

     &nbs= p;            &= nbsp;   Figure 13: Recursive Signaling

[Jon5] Note: It is possible that Cc actually is a gateway = – which would be client managed and is the border point

[Med] Y= es, Cc may a be “client-side DOTS gateway” or “Client Dom= ain Managed DOTS gateway” if you will :)

&n= bsp;

We do h= ave this text (that may be tweaked):

&n= bsp;

   In ord= er to prevent leaking internal information outside a client-

   domain= , DOTS gateways located in the client-domain SHOULD NOT reveal

   the id= entification information that pertains to internal DOTS clients<= /span>

   (clien= t-identifier) unless explicitly configured to do so.

[Jon4] I had always read this as being a DOTS gateway on t= he border of a different client and server domain

[Med] T= he mention which is important in that text is: “DOTS gateways located in the client-domain”.<= /span>

[Jon5] Agreed.  However, if there are multiple gatewa= ys in the chain, all client managed, it is only the one on the border with = a server domain that needs to be extra careful.

&n= bsp;

&n= bsp;

[Jon3] “Client-side DOTS gateways” may, or may= not, want to pass on “client-identifiers” (which are obfuscate= d to hide identity).  If they do not pass on “client-identifiers= ” then the DOTS server they connect to (which is in the same domain by defin= ition) will not be able to differentiate between the different clients R= 11; the whole purpose of “client-identifiers” – or am I m= issing something here?

[Med] F= or client-side DOTS gateways, the server does not need to rely upon the ide= ntity of internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS cli= ents and a DOTS gateway located on the CPE that intercepts all messages fro= m these clients. The ultimate DOTS server does not to know about those DOTS= clients.<= /span>

[Jon4] Again an example of a DOTS gateway that sits both i= n a client and (different) server domain.

[Med] T= he CPE is in the border from a connectivity standpoint, but for DOTS, the g= ateway is under the control of the client. I don’t see the “server domain” part in this example.

[Jon5] Again a disconnect in our interpretation, now under= stood.  To me the gateway (albeit it client managed) is the border bet= ween the client and server domains.

[Med] L= et’s fix the wording to avoid confusion.

 <= o:p>

&n= bsp;

&n= bsp;

[Jon3] To me, the only time that “client-identifiers= ” may need to be dropped (not that I recommend doing this) is when a = DOTS Gateway is sitting in both a client’s domain and a different server’s domain as a domain border gateway.

&n= bsp;

“= to propagate the DOTS client identity from the gateway's

   &= nbsp;  client-side to the gateway's server-side, and from the gateway'= s

   &= nbsp;  server-side to the DOTS server. ”

&n= bsp;

   &= nbsp;  DOTS gateway in a manner that ensures that there is zero

   &= nbsp;  probability that the same value will be assigned to a different=

   &= nbsp;  DOTS client.  The server-side DOTS gateway MUST conceal

   &= nbsp;  potentially sensitive DOTS client identity information.

 

   &= nbsp;  If aggregating DOTS mitigation requests received from multiple<= o:p>

   &= nbsp;  DOTS clients is enabled, the server-side DOTS gateway has to in= clude

   &= nbsp;  a list of 'client-identifier' values; each value is pointing to= a

   &= nbsp;  DOTS client.  It is out of scope of this document to speci= fy how

[Jon1] I prefer “a list of 'client-identifier' value= s; each value is pointing to a unique

      DOTS client that is in the = aggregated list.  It is out of….”

&n= bsp;

[Med] D= eal.  

&n= bsp;

   &= nbsp;  aggregation is implemented by a DOTS gateway.=

 

   &= nbsp;  The client-identifier attribute MUST NOT be generated and inclu= ded

   &= nbsp;  by DOTS clients.

 

   &= nbsp;  DOTS servers MUST ignore client-identifier attributes that are<= o:p>

   &= nbsp;  directly supplied by source DOTS clients.  This implies th= at first

   &= nbsp;  server-side DOTS gateways MUST strip client-identifier attribut= es

   &= nbsp;  supplied by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS clie= nt and the client component of a DOTS gateway (i.e. server-facing-side) as = seen by a DOTS server?  There is nothing that I have spotted for this in the DOTS signal protocol.

&n= bsp;

[Med] I= confirm, there is no such text in the draft. A deployment would consist in= explicitly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is coming= from a server-side gateways in that list.

 

[Jon2] Then do we need to instruct the implementers of the= signal channel that this is what should be done?

[Med] W= hat about adding this text:

&n= bsp;

NEW:

   &= nbsp;  DOTS servers MAY support a

   &= nbsp;  configuration parameter (e.g., ACLs) to identify DOTS gateways<= o:p>

   &= nbsp;  that are trusted to supply client-identifier attributes.

[Jon4] I do not think ACL is the right term here.  In= the same way the a DOTS server needs to know the valid client IDs of the D= OTS clients that can use it (along with the valid target IP addresses etc.) “valid gateway” could be added= in.  I would just drop “(e.g. ACLS)”.

[Med] D= ropped.

=  

[Jon1] I do agree that true DOTS clients MUST NOT generate= ‘client-identifiers’. If only the DOTS gateway server componen= t (client-facing-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this = issue as it is only the DOTS server component who is allowed to do the gene= ration.

 

[Jon1] In my implementation the DOTS server (gateway or no= t) always generates a client-identifier (will be changed if there already i= s a unique identifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can = differentiate between the same mitigation-id from different clients.

[Med] O= k, thanks.

 

   &= nbsp;  This is an optional attribute.

 

2nd change: Delete t= his text because client-identifier is uniquely assigned by the first server= -side gateway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

   If the= 'client-identifier' value is already present in the

   mitiga= tion request received from the DOTS client, the DOTS gateway

   MAY co= mpute the 'client-identifier' value, as discussed above, and

   add th= e computed 'client-identifier' value to the end of the 'client-<= /span>

   identifier' list.

[Jon1] OK

 

Comments and modifications are = more welcome.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.o= rg; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …but broken clients= may communicate directly with servers without any gateway on the path.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 

[Med] Actually,

=B7    &n= bsp;    (R1) we do need MUST so= that as a general rule clients do not insert a client-id parameter in thei= r requests.

=B7    &n= bsp;    And (R2) DOTS servers M= UST ignore client-ids that are supplied by the origin DOTS clients.

 

In deployments without gateways= , client-ids supplied by broken DOTS clients will be ignored by the server = as per R2.

In deployments with gateways, t= he first server-side gateway will follow R2 and strip any value supplied by= the client.

 

If we add text to cover (R2), I= don’t think we need a sentence about updating the content because cl= ient-id is a value that is ***assigned*** exclusively by a dots gateway:

 

   &= nbsp;  The 'client-identifier' value MUST be assigned by the DOTS gate= way

   &= nbsp;           &nbs= p;            &= nbsp;       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^  

   &= nbsp;  in a manner that ensures that there is zero probability th= at the

   &= nbsp;  same value will be assigned to a different DOTS client. 

 

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for sharing your thou= ghts.

 

Please see comments inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There are also some compl= ications even when no aggregation is in use. See below.

 

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client (C1aj) -----------= -------------------------- (S1j) DOTS gateway J (C2j) ----------\ &nbs= p;

DOTS client (C1bj) -----------= -----------------------------/       &nb= sp;             = ;            &n= bsp;|

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;|

DOTS client (C1ax) ----- (S1x)= DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3) &n= bsp; 

DOTS client (C1bx) --------/&n= bsp;            = ;            &n= bsp;     |      &nbs= p;            &= nbsp;           

     =             &nb= sp;            =             &nb= sp;            =     |        &n= bsp;            = ;            

DOTS client (C1ay) ----- (S1y)= DOTS gateway Y (C2y) -------/       &nb= sp;            =              

DOTS client (C1by) --------/&n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 

[Med] This assumes that the DOT= S forwarding path will always be the same (that is, the same set of gateway= s will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree for the first serve= r-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 

[Med]I do see some implications of this design in a multi-homing scenario with the same mitigation provider: the same request from a multi-= homed DOTS client will be presented to the server as being distinct request= s…while this is not. It may be the same request that is forked among = existent network attachments or a request that is sent over a first link, but a subsequent one over another link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’m referring to th= is “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, these are deploymen= t-specific. My concern is to avoid design choices that make hidden assumpti= ons.  

 

 

[Med] Separating both client-id from gateway-id does = not suffer from this issue (even when no aggregation).    

 

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we agree that one (uni= que) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 

[Med] I guess you meant “= restrict the number of aggregated clients per DOTS gateway”, not the = “number of DOTS clients serviced by a DOTS gateway”. I would say this is deployment-specific. A deployment that enables signal/data cha= nnel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please note that I used &= #8220;good/bad deployment choices&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 

To avoid potential conflicts and also in or= der to help the server select the appropriate policy to enforce, signal/dat= a channel protocol drafts specify a parameter called “client-identifier”. The design allows this parameter to carry= multiple values.

 

Putting aside the extensibility argument of= the data model, the signal/data channel protocol drafts are silent about t= he exact use of multiple values.

 

The potential deployment cases for multiple= values are (without making any assumption whether these cases are good/bad= deployment choices):

 

(1)<= /span>Multiple gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)<= /span>Requests from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 

The current approach has the merit to not m= ake any assumption on the gateway behavior (e.g., (2)), but it leads to a c= onfusion. For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS = clients or to a DOTS client and a set of on-path gateways. The protocol doc= uments need to be updated to avoid such confusion. Two options are listed b= elow:

 

Option 1 (Avoid making any assumption on ga= teways/proper semantic distinction between clients and on-path gateways)

-    Restrict the usage of ‘client= -identifier’ to carry identifiers of clients, not gateways.

-    On-path gateways may include a new = parameter called ‘gateway-identifier’ to ease contexts retrieva= l and avoid potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with ‘clie= nt-identifier’ pointing to C

G2 will update the request with ‘gate= way-identifier’ pointing to G1

 

Option 2 (Describe what a gateway cannot do= )

-    Update the architecture document to= indicate that requests are not aggregated by a dots gateway.

-    ‘client-identifier’ inc= ludes multiple values only and only if multiple gateways are on-path. The o= rder of the values is important because the first one will be the one pointing to the source DOTS clients.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with ‘clie= nt-identifier’ pointing to C

G2 will update the request with ‘clie= nt-identifier’ pointing to G1 (in addition to C)

 

We are seeking for feedback from the WG on = which direction to take.

 

Thoughts?

 

Cheers,

Med

 

 

 

--_000_787AE7BB302AE849A7480A190F8B93300A09AA97OPEXCLILMA3corp_-- From nobody Tue Dec 19 02:49:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555912D87E for ; Tue, 19 Dec 2017 02:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKctMOC1zktf for ; Tue, 19 Dec 2017 02:49:10 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6662A126B71 for ; Tue, 19 Dec 2017 02:49:10 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRFSO-00050Y-Rr; Tue, 19 Dec 2017 10:49:08 +0000 From: "Jon Shallow" To: , References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 19 Dec 2017 10:49:09 -0000 Message-ID: <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A4_01D378B7.002A8050" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGht6CjVFygIRhvgE++pwgRVUADvAFJBRQ9o6OuIqA= Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:49:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A4_01D378B7.002A8050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:02 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats =20 Hi Jon,=20 =20 Thank you for initiating this thread. This is exactly the discussion I wanted to have.=20 =20 The initial requirement that motivated introducing config-interval was = the following from the requirements I-D: =20 When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. =20 Also, given that configuration changes may occur at the server, clients = will continue using stale configuration data retrieved previously from the = server because there is no procedure to refresh the config. This is = undesirable. config-interval solves this. Of course, DOTS agents may decide to = disable the refresh procedure by setting it to 0 or by not returning the = parameter. [Jon] I agree there may be stale signal configurations (most likely to = occur during initial set-up and tuning) and =93config-interval=94 will handle = this. The requirements I-D refer to this only being done when =91no mitigation request is active=92. The peacetime/attack (with possibly) alternative heartbeat configurations partially handle this requirement as well. =20 Having distinct heartbeat values (peacetime/attack) is an option, but it does not address the issue of stale configuration. Note that, for = example, a distinct max-retransmit may also be configured for peace time.=20 =20 The following would meet all the requirements: =20 =20 +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 [Jon] A minor comment =96 is the following more logical and more = descriptive? +--:(configuration) +--rw session-id int32 +--rw attack-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw peace-time-config? | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw config-interval? int32 =20 =B7 If no peace-time-config is provided, the same values will be = used for both peace and attack times till a change occurs. This is what is currently in the draft.=20 =B7 peace-time-config may be returned to specify values to be = used for peacetime. Switching between attack/peace time parameter values will be automatic. [Jon] We just need to make sure the =91automatic=92 switching is defined = in the text as well as updating CBOR mappings etc. =20 [Jon] How do we handle in the YANG definition the fact that, say, when = doing a GET, heartbeat-interval is =93heartbeat-interval=94:{=93current-value=94:xx,=94min-value=94:yy,=94ma= x-value=94:zz}, but a PUT currently is {=93heartbeat-interval=94:aa}. I think actually the = PUT should be {=93heartbeat-interval=94:{=93current-value=94:aa} and the = YANG definition updated accordingly. =20 Your point (A) makes sense to me. What about adding the following: =20 NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. [Jon] Works for me =20 I do fully agree that consistent setting of the parameters is important. = =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats =20 Hi there, =20 There has been a lot of discussion on this, culminating in an update in draft-ietf-dots-signal-channel-13 where =91config-interval=92 has been = added in to try to handle the different concerns. =20 >From my trying to simplify things perspective:- =20 1. NAT devices usually allow outbound session requests (source IP = nat=92ing) and allow for a response to come back within a defined time frame (lots = of discussion on this time frame =96 eventually setting on 30 seconds as a = good compromise =96 but could be longer). =20 2. NAT devices may be configured to allow inbound session requests (port redirection) and allow for a response to come back within a defined time frame. Doing this does raise security policy issues as this potentially allows uncontrolled access from the Internet to an internal device. =20 3. NAT devices are likely to break any server initiated heartbeats if = the server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security reasons). =20 4. The frequency of Heartbeats ideally are different between peace time = and attack. In peace time there could be no heartbeats or at a slow rate to keep the signal channel alive. In attack time, 30 seconds appears to be = the agreed compromise time, but this is also influenced by the underlying = COAP protocol (retry intervals and counters etc.). In attack time, the rate should be sufficient to detect any transmission issues within a = reasonable time frame. =20 5. For DOTS clients, there should be no issues with heartbeats going = through NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. =20 6. For DOTS servers dropping the heartbeat rate below that of the active = NAT session time will cause issues if there is a NAT device that does not = allow inbound initiated sessions. =20 7. If heartbeats are in use, then both DOTS server and DOTS client have = to do their separate heartbeats for network connectively / DOTS agent availability. =20 8. If heartbeats are being used, the DOTS server can optionally trigger mitigation is heartbeats stop working =20 To give the ability to change the heartbeat rates, =91config-interval=92 = has been added to the signal draft. A client then knows when to re-request = the configuration (e.g. for potentially changed heartbeat values). However, =91config-interval=92 has to be sufficiently large to not compete with = the heartbeat rate (if they both were for the same interval, then = configuration update requests would effectively be doing the same task as = heartbeats!). But if =91config-interval=92 is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get increased = in attack time (and if the config update response packet does not get = through, it will not get updated). I think =91config-interval=92 needs to be = thought through further. =20 I have 2 proposals here =20 A. If the heartbeat frequency is below that of the NAT session inactive timeout, the DOTS client will always transmit the heartbeats at the appropriate frequency. When the heartbeat request arrives at the DOTS server, this triggers a heartbeat process on the DOTS server to then heartbeat test the DOTS client. Thus the DOTS server can use the = =93warm=94 NAT session during peacetime. If the heartbeat requests do not come in from = the DOTS client (and a peacetime heartbeat rate is configured) then auto-mitigation can get invoked if required. =20 B. There are defined two heartbeat rates =96 one for when one or more mitigation requests are in progress (attack situations) and a second = rate for peace time (can be 0 (no heartbeats) or some long timeout). = Whenever the first mitigation is requested over a DOTS session, both ends start heart-beating at the =93attack=94 rate. This gets rid of any potential =91config-interval=92 refresh delays / =91new heartbeat interval=92 = packets getting lost. When there are no more mitigations active for that DOTS session, = then the DOTS session drops immediately back into the peacetime values. =91config-interval=92 could then be replaced with =91peace-time-heartbeat-interval=92. =20 Regards =20 Jon =20 =20 ------=_NextPart_000_03A4_01D378B7.002A8050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 19 December 2017 = 10:02
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal Channel Heartbeats

 

Hi Jon,

 

Thank you for initiating this thread. This is = exactly the discussion I wanted to have.

 

The initial requirement that motivated = introducing config-interval was the following from the requirements = I-D:

 

      = When DOTS agents are exchanging heartbeats and = no

      = mitigation request is active, either agent MAY request changes = to

      the = heartbeat rate.  For example, a DOTS server might want = to

      = reduce heartbeat frequency or cease heartbeat exchanges when = an

      = active DOTS client has not requested mitigation, in order = to

      = control = load.

 

Also, given that configuration changes may = occur at the server, clients will continue using stale configuration = data retrieved previously from the server because there is no procedure = to refresh the config. This is undesirable. config-interval solves this. = Of course, DOTS agents may decide to disable the refresh procedure by = setting it to 0 or by not returning the parameter.

[Jon] I = agree there may be stale signal configurations (most likely to occur = during initial set-up and tuning) and “config-interval” will = handle this. The requirements I-D refer to this only being done when = ‘no mitigation request is active’. =A0The peacetime/attack = (with possibly) alternative heartbeat configurations partially handle = this requirement as well.

 

Having distinct heartbeat values = (peacetime/attack) is an option, but it does not address the issue of = stale configuration. Note that, for example, a distinct max-retransmit = may also be configured for peace time.

 

The following would meet all the requirements: =  

 

          =
+--:(configuration)
          =
   +--rw =
session-id          &nb=
sp; int32
          =
   +--rw heartbeat-interval?   =
int16
          =
   +--rw missing-hb-allowed?   =
int16
          =
   +--rw max-retransmit?       =
int16
          =
   +--rw =
ack-timeout?          =
int16
          =
   +--rw ack-random-factor?    =
decimal64
          =
   +--rw trigger-mitigation?   =
Boolean
          =
   +--rw peace-time-config
    =
         |   =
+--rw heartbeat-interval?   =
int16
    =
         |   =
+--rw missing-hb-allowed?   =
int16
        =
     |   +--rw =
max-retransmit?       =
int16
          =
   |   +--rw =
ack-timeout?          =
int16
          =
   |   +--rw ack-random-factor?    =
decimal64
          =
   +--rw config-interval?      =
int32

[Jon]=A0 A minor comment – is the = following more logical and more = descriptive?

          =
+--:(configuration)
          =
   +--rw =
session-id          &nb=
sp; int32
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw =
attack-time-config
          =
   |=A0=A0 +--rw heartbeat-interval?   =
int16
          =
   |=A0=A0 +--rw missing-hb-allowed?   =
int16
          =
   |=A0=A0 +--rw =
max-retransmit?       =
int16
          =
   |=A0=A0 +--rw =
ack-timeout?          =
int16
          =
   |=A0=A0 +--rw ack-random-factor?    =
decimal64
          =
   +--rw peace-time-config?
    =
         |   =
+--rw heartbeat-interval?   =
int16
    =
         |   =
+--rw missing-hb-allowed?   =
int16
        =
     |   +--rw =
max-retransmit?       =
int16
          =
   |   +--rw =
ack-timeout?          =
int16
          =
   |   +--rw ack-random-factor?    =
decimal64
          =
   +--rw trigger-mitigation?   =
Boolean
          =
   +--rw config-interval?      =
int32

 

=B7         = If no peace-time-config is provided, the same = values will be used for both peace and attack times till a change = occurs. This is what is currently in the draft.

=B7         = peace-time-config may be returned to specify = values to be used for peacetime. Switching between attack/peace time = parameter values will be automatic.

[Jon] We = just need to make sure the ‘automatic’ switching is defined = in the text as well as updating CBOR mappings = etc.

 

[Jon] How = do we handle in the YANG definition the fact that, say, when doing a = GET, heartbeat-interval is = “heartbeat-interval”:{“current-value”:xx,”m= in-value”:yy,”max-value”:zz}, but a PUT currently is = {“heartbeat-interval”:aa}.=A0 I think actually the PUT = should be = {“heartbeat-interval”:{“current-value”:aa} and = the YANG definition updated accordingly.

 

Your point (A) makes sense to me. What about = adding the following:

 

NEW:

   In order to avoid complications due to the =
presence of some stateful
   translators and firewalls (e.g., discard an =
incoming packet because
   no matching state is found), DOTS servers MAY =
trigger their heartbeat
   requests immediately after receiving heartbeat =
probes from peer DOTS
   clients.
[Jon] Works for me

 

I do fully agree that consistent setting of = the parameters is important.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de = Jon Shallow
Envoy=E9 : lundi 18 d=E9cembre 2017 = 16:00
=C0 : dots@ietf.org
Objet : [Dots] = Signal Channel Heartbeats

 

Hi there,

 

There has = been a lot of discussion on this, culminating in an update in = draft-ietf-dots-signal-channel-13 where ‘config-interval’ = has been added in to try to handle the different = concerns.

 

From my trying to simplify things = perspective:-

 

1. NAT devices usually allow outbound session requests = (source IP nat’ing) and allow for a response to come back within a = defined time frame (lots of discussion on this time frame – = eventually setting on 30 seconds as a good compromise – but could = be longer).

 

2. NAT devices may be configured to allow inbound = session requests (port redirection) and allow for a response to come = back within a defined time frame.  Doing this does raise security = policy issues as this potentially allows uncontrolled access from the = Internet to an internal device.

 

3. NAT = devices are likely to break any server initiated heartbeats if the = server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security = reasons).

 

4. The frequency of Heartbeats ideally are different = between peace time and attack.  In peace time there could be no = heartbeats or at a slow rate to keep the signal channel alive.  In = attack time, 30 seconds appears to be the agreed compromise time, but = this is also influenced by the underlying COAP protocol  (retry = intervals and counters etc.).  In attack time, the rate should be = sufficient to detect any transmission issues within a reasonable time = frame.

 

5. For DOTS clients, there should be no issues with = heartbeats going through NAT devices (other than during an attack where = there may be packet loss) no matter what the heartbeat frequency = is.

 

6. For DOTS servers dropping the heartbeat rate below = that of the active NAT session time will cause issues if there is a NAT = device that does not allow inbound initiated sessions.

 

7. If = heartbeats are in use, then both DOTS server and DOTS client have to do = their separate heartbeats for network connectively / DOTS agent = availability.

 

8. If heartbeats are being used, the DOTS server can = optionally trigger mitigation is heartbeats stop = working

 

To give the ability to change the heartbeat rates, = ‘config-interval’ has been added to the signal draft.  = A client then knows when to re-request the configuration (e.g. for = potentially changed heartbeat values).  However, = ‘config-interval’ has to be sufficiently large to not = compete with the heartbeat rate (if they both were for the same = interval, then configuration update requests would effectively be doing = the same task as heartbeats!).  But if = ‘config-interval’ is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get = increased in attack time (and if the config update response packet does = not get through, it will not get updated).  I think = ‘config-interval’ needs to be thought through = further.

 

I have 2 proposals here

 

A. If the = heartbeat frequency is below that of the NAT session inactive timeout, = the DOTS client will always transmit the heartbeats at the appropriate = frequency.  When the heartbeat request arrives at the DOTS server, = this triggers a heartbeat process on the DOTS server to then heartbeat = test the DOTS client.  Thus the DOTS server can use the = “warm” NAT session during peacetime.  If the heartbeat = requests do not come in from the DOTS client (and a peacetime heartbeat = rate is configured) then auto-mitigation can get invoked if = required.

 

B. There are defined two heartbeat rates – one = for when one or more mitigation requests are in progress (attack = situations) and a second rate for peace time (can be 0 (no heartbeats) = or some long timeout).  Whenever the first mitigation is requested = over a DOTS session, both ends start heart-beating at the = “attack” rate.   This gets rid of any potential = ‘config-interval’ refresh delays / ‘new heartbeat = interval’ packets getting lost.  When there are no more = mitigations active for that DOTS session, then the DOTS session drops = immediately back into the peacetime values.  = ‘config-interval’ could then be replaced with = ‘peace-time-heartbeat-interval’.

 

Regards

 

Jon

 

 

------=_NextPart_000_03A4_01D378B7.002A8050-- From nobody Tue Dec 19 03:12:49 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD3E127871 for ; Tue, 19 Dec 2017 03:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjMWW6bcYCRv for ; Tue, 19 Dec 2017 03:12:43 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C3912025C for ; Tue, 19 Dec 2017 03:12:42 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513681961; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=J BTD0tCaJL8pMt8zYzzUtH+Ffm+pgYDxRNdaLH8pV0 s=; b=DChM88+BljQJvXwHxR7n9fZ8yMUC5e6ee7Jfcr5cYh8Q tqV/3b/i//4ofjrnsu2LD05Jr7O3SnlpvIbksNN8868biLYO1I APk/Q7q/WZyspPxdLooWeTPqyk8oJs2ZxYWuOFMB5vjj9LtfFb 5+hR1zyZ+mGFAEsIrkVS2ZZOSks= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 0e1f_a92d_0f2f7bab_72a1_4ff8_9d71_be059a6648e2; Tue, 19 Dec 2017 05:12:40 -0600 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 06:12:37 -0500 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 06:12:36 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 19 Dec 2017 06:12:36 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 06:12:34 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 11:12:33 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 11:12:33 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" , "kaname nishizuka" Thread-Topic: [Dots] client-identifier: Recurisve signaling & Aggregation Thread-Index: AdN1r8EWZB+xXOR9RTS61I4qkE2rowNCop6fAX9a7Vmg0d1E4KDzX4gQweavL4D8MrPggIAACUaAgAAGlICAAAZkAIAACMsAgAAFJACAAAc0gIAA95IAgAAtF4CAAAcJAP//8uQA Date: Tue, 19 Dec 2017 11:12:33 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A099584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <015b01d376ac$6cbe4e20$463aea60$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A099D30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d377ec$897352e0$9c59f8a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A149@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09A18F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <028f01d37807$a547b2c0$efd71840$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A203@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b101d3780f$91deb2d0$b59c1870$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A2A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ee01d37817$29d3be80$7d7b3b80$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <031001d3781d$55f34f70$01d9ee50$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09A920@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <036f01d378af$aa8550f0$ff8ff2d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09AA97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:T79dWRQ/emgQ8mbc14TnoQFYHgm2LsgfNcLXpHV0tMTrMNg7K8cv8ufkWNsCPH6AFbyBzcmCYHh5vURR8XTJew+oUnI7ImGiZwVSrftspSXqKSB07zwcVopWGfwE9Z0OvynN8cV1VOwZZkL4vFtFc05U7Ccv6LbZ82mvpAFdo9r8NtdqshJqFGXD9in+XHydA53T5vY3xnfbJjtxVdjzus4VCLqu/zSveUhcUfQPZBG9/Xqmmg/w/NGfWmYYv/Ygn+Y1Wsz9KTSovtU1Io05PCCZAed4IiK/AM7wlLWJcNsCEFM95bQkyFnePDXnMgSwtE7HQNIT+FqOI95zTjAMkQq95nEJ6vCXIt8BgFUvivk=; 5:yZ0oLQBm9P25p6ys2pE1Lh47B5icC1pB4jM4DLdjTn9scLj+w/wTI5mOcBGf9mML6ijXtYT57uFxSWnf1Nrm2GR0H92VY97b9zIpE64cXhW316Feg9aciY7acehz19++9wpmLmxsQbbYGRBRxQ+EMHdp56AcfLpuDYTCs+wGRzo=; 24:laubbiaSmyD6qiY7/mJgnUj+1Q079oy/hEEgFWGKEq/KATvMuRSQxwE3AxFmm3nBhgrPMO4U/WTzA40IcM/llxaKiOgguGdLLJCwzzhboEY=; 7:Tpap9EH8F8VKHsMF7VkjeqQS2isGIp9HUN99HqqFoelrOTAyF1p/9+vc6H8RssNTVDVUUbaVgojaGd3RqkIjqKbiyutBTZNT6qXDUPju3wzPaGnkPiwB5VE6wI2FR5OlTqXxcEVgHFxljIin63nlkAXT29oZjMAD2uginX28HNn6HGlMtQG/fRYIjfc4yVO6yAg9XYV31CINq0RLD2mF+aLUCFVBr92wdn3sYQGF3d9a55gxKgp1RdZbKY3FY6yk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e63e125f-a566-4f04-57d3-08d546d16701 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(3231023)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(396003)(51444003)(189003)(32952001)(57704003)(199004)(53754006)(33656002)(5660300001)(72206003)(102836003)(790700001)(3846002)(8936002)(55016002)(2950100002)(14454004)(68736007)(6436002)(229853002)(110136005)(6506007)(2900100001)(97736004)(9686003)(53546011)(86362001)(236005)(6306002)(6116002)(93886005)(478600001)(53936002)(3660700001)(53946003)(345774005)(54896002)(19609705001)(105586002)(25786009)(106356001)(81166006)(3280700002)(77096006)(8676002)(5890100001)(80792005)(66066001)(316002)(2501003)(2906002)(7696005)(7736002)(74316002)(76176011)(16200700003)(81156014)(6246003)(59450400001)(99286004)(21314002)(85282002)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883109E71C5F602FE25E55EA0F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e63e125f-a566-4f04-57d3-08d546d16701 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 11:12:33.0699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6182> : inlines <6262> : streams <1773560> : uri <2553756> Archived-At: Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:12:49 -0000 --_000_DM5PR16MB17883109E71C5F602FE25E55EA0F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think the functionality of DOTS gateway needs to be complicated by = aggregating mitigation requests and forking responses. The drafts need to c= larify that DOTS gateway only performs aggregation at session-level but not= at the request-level. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Tuesday, December 19, 2017 3:52 PM To: Jon Shallow ; dots@ietf.org; kaname nishizuk= a Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 19 d=E9cembre 2017 10:57 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, "[Med] I suspect the disconnect is caused by mixing connectivity and DOTS c= ontrol aspects" Ahh - the light bulb has gone off - why our discussions had a disconnect. = It is down to the interpretation of the word "side" as used in "Client Side= DOTS gateway". To you it meant "control or ownership", to me "connectivit= y or position relative to DOTS gateway". [Med] Yes, indeed. To prevent others getting confused, my suggestion would be to update the fo= llowing in the various draft specs "Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway" "Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway" "DOTS gateway server-side" to "DOTS gateway server-facing-side" "DOTS gateway client-side" to "DOTS gateway client-facing-side" The latter 2 should be defined somewhere. [Med] I extracted this comment and sent it as a comment to the ongoing WGLC= on the requirements I-D. The signal channel/data channel drafts will be up= dated to reflect whatever change will be endorsed in the requirements I-D. To me, a gateway is a border of some sort - where there is a potential disc= ontinuity of flow (e.g. aggregation, client/server etc.) Otherwise, see inline [Jon5]. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 07:15 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 17:29 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, See inline [Jon4]. I have deleted some of the "see inline messages". Regards Jon De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 14:54 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med, Going in the right direction, but see comments inline [Jon1]. As a side comment, I always have to think twice what "DOTS gateway server-s= ide" actually means. It actually means the DOTS client component logic of = a DOTS gateway. There is no definition of terms in the signal channel draf= t, but the definition could perhaps be added to the dots requirements draft= . Others may also get confused about this. Perhaps "DOTS gateway server-f= acing-side" is clearer, even though much longer to type! [Med] We do have the following definition in the requirements I-D: Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS gateways that are in the DOTS server's domain. [Jon2] Yes - actually, this adds to the confusion in my mind. For a singul= ar DOTS gateway, it could have a client-facing-side that is in the DOTS cli= ent domain, and a server-facing side that is in a different DOTS server dom= ain. The quoted text implies it is one or the other, but not both. [Med] Do you have a particular case in mind in which we should allow for th= e "client-facing side" of a gateway to belong to the client domain and its = "server-facing side" to belong to the server domain? [Jon3]The recursive gateway comes immediately to mind - when an ISP cannot = handle the current attack and wants to invoke someone else to handle it. O= therwise to me, a gateway to me is either an aggregation point of clients w= ithin a common domain or a border between two different domains. [Med] Given that recursive signalling is opaque to the origin DOTS client, = all involved gateways are IMHO at the server-side (from the perspective of = the source client). The only difference is that the intermediate dots gatew= ay (server) is managed by Provider 1 while the final server is managed by a= nother provider. [Jon4] Hmm - I am not convinced. Some of your examples below actually give= examples for a DOTS gateway sitting in both client and (different) server = domains. [Med] I suspect the disconnect is caused by mixing connectivity and DOTS co= ntrol aspects. [Jon5] Thanks - this is the cause of our disconnect in interpretation of "s= ide" - well spotted [Jon2] Also, being picky, does "Client-side DOTS gateway" (type of DOTS gat= eway) actually mean the same as "DOTS gateway client-side" (component withi= n a DOTS gateway)? [Med] No. Those are two distinct things/dimensions: - "xxx-side DOTS gateway" means this is owned and operated by xxx. - "DOTS gateway client-side" refers to the client-facing interface of a = DTOS gateway. It applies for both client- and server-side getaways. [Jon3] I agree with your distinct definitions, but not the use of the defin= ition in the requirements I-D to cover the definition of "DOTS Gateway clie= nt-side" Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 13:04 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Jon, Please see below two proposed changes to hopefully conclude on the issues d= iscussed in this thread: 1st change: OLD: client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. This allows the DOTS server to accept mitigation requests with scopes which the DOTS client is authorized to manage. The 'client-identifier' value MUST be assigned by the DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The DOTS gateway MUST conceal potentially sensitive DOTS client identity information. The client-identifier attribute SHOULD NOT be generated and included by the DOTS client. This is an optional attribute. NEW: client-identifier: The client identifier MAY be conveyed by a server-side DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. 'client- identifier' MAY be used by the final DOTS server for policy enforcement purposes. The 'client-identifier' value MUST be assigned by the server-side [Jon1] Actually, as the client and server components of a DOTs gateway are= separate (the server-facing component has no real knowledge of what is hap= pening on the client-facing side), it needs to be the client-facing-side of= the DOTS gateway that assigns the (unique) client-identifier which is then= passed over to the server-facing-side for onward transmission. [Med] You are right if we zoom on the internal implementation of a DOTS gat= eway. This part of the text focuses on the external behavior of the DOTS ga= teway. The text does not need to zoom in given that the second sentence abo= ve says; [Jon2] In terms of helping the implementers, the use of only DOTS server be= ing allowed to generate a 'client-identifier' as discussed later. If "serv= er-side" was removed as in :- "client-identifier: The client identifier MAY be conveyed by a DOTS gateway to propagate the DOTS client identity ..." Removes a lot of confusion in my mind. [Med] The "server-side" is important because we don't want client-side GWs = to reveal the identity of internal dots clients. [Jon3] Why do we need to be restrictive to "Server-side DOTS gateways" here= ? [Med] For privacy concerns: e.g., avoid revealing how/where DOTS clients ar= e deployed in the client's domain. [Jon4] But all this (deployment etc.) information is in the client domain o= nly using your definition of a client-side DOTS gateway - so within the cli= ent space who the really cares? [Jon4] But this information going into another domain is the security conce= rn. However, to get a mitigation request to go between domains, there has = to be a border at some point. How do we handle that? What does the border= look like (it cannot be a client-side or server-side DOTS gateway as that = is not allowed to straddle domains as you assert)? [Med] It looks like what is described in the architecture draft: a gateway = located in the server-side. example.net domain . . . . . . . . . . . . . . . . . . Gn . +----+ 1 . +----+ +-----------+ . | Cc |<--------->| Sn |~~~~~~~| Mitigator | . +----+ . +=3D=3D=3D=3D+ | Mn | . . | Cn | +-----------+ . example.com . +----+ . client . ^ . . . .|. . . . . . . . . . . . . . | 1 | | . . .|. . . . . . . . . . . . . . . v . . +----+ +-----------+ . . | So |~~~~~~~| Mitigator | . . +----+ | Mo | . . +-----------+ . . . . . . . . . . . . . . . . . . . . example.org domain Figure 13: Recursive Signaling [Jon5] Note: It is possible that Cc actually is a gateway - which would be = client managed and is the border point [Med] Yes, Cc may a be "client-side DOTS gateway" or "Client Domain Managed= DOTS gateway" if you will :) We do have this text (that may be tweaked): In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. [Jon4] I had always read this as being a DOTS gateway on the border of a di= fferent client and server domain [Med] The mention which is important in that text is: "DOTS gateways locate= d in the client-domain". [Jon5] Agreed. However, if there are multiple gateways in the chain, all c= lient managed, it is only the one on the border with a server domain that n= eeds to be extra careful. [Jon3] "Client-side DOTS gateways" may, or may not, want to pass on "client= -identifiers" (which are obfuscated to hide identity). If they do not pass= on "client-identifiers" then the DOTS server they connect to (which is in = the same domain by definition) will not be able to differentiate between th= e different clients - the whole purpose of "client-identifiers" - or am I m= issing something here? [Med] For client-side DOTS gateways, the server does not need to rely upon = the identity of internal DOTS clients; the identity of the gw is sufficient= . Imagine an enterprise network with multiple DOTS clients and a DOTS gatew= ay located on the CPE that intercepts all messages from these clients. The = ultimate DOTS server does not to know about those DOTS clients. [Jon4] Again an example of a DOTS gateway that sits both in a client and (d= ifferent) server domain. [Med] The CPE is in the border from a connectivity standpoint, but for DOTS= , the gateway is under the control of the client. I don't see the "server d= omain" part in this example. [Jon5] Again a disconnect in our interpretation, now understood. To me the= gateway (albeit it client managed) is the border between the client and se= rver domains. [Med] Let's fix the wording to avoid confusion. [Jon3] To me, the only time that "client-identifiers" may need to be droppe= d (not that I recommend doing this) is when a DOTS Gateway is sitting in bo= th a client's domain and a different server's domain as a domain border gat= eway. "to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server. " DOTS gateway in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. The server-side DOTS gateway MUST conceal potentially sensitive DOTS client identity information. If aggregating DOTS mitigation requests received from multiple DOTS clients is enabled, the server-side DOTS gateway has to include a list of 'client-identifier' values; each value is pointing to a DOTS client. It is out of scope of this document to specify how [Jon1] I prefer "a list of 'client-identifier' values; each value is pointi= ng to a unique DOTS client that is in the aggregated list. It is out of...." [Med] Deal. aggregation is implemented by a DOTS gateway. The client-identifier attribute MUST NOT be generated and included by DOTS clients. DOTS servers MUST ignore client-identifier attributes that are directly supplied by source DOTS clients. This implies that first server-side DOTS gateways MUST strip client-identifier attributes supplied by DOTS clients. [Jon1] How do we differentiate between an actual DOTS client and the client= component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS se= rver? There is nothing that I have spotted for this in the DOTS signal pro= tocol. [Med] I confirm, there is no such text in the draft. A deployment would con= sist in explicitly configuring a list of gateways (ACLs) on the server; the= server will trust client-id if and only if it is coming from a server-side= gateways in that list. [Jon2] Then do we need to instruct the implementers of the signal channel t= hat this is what should be done? [Med] What about adding this text: NEW: DOTS servers MAY support a configuration parameter (e.g., ACLs) to identify DOTS gateways that are trusted to supply client-identifier attributes. [Jon4] I do not think ACL is the right term here. In the same way the a DO= TS server needs to know the valid client IDs of the DOTS clients that can u= se it (along with the valid target IP addresses etc.) "valid gateway" could= be added in. I would just drop "(e.g. ACLS)". [Med] Dropped. [Jon1] I do agree that true DOTS clients MUST NOT generate 'client-identifi= ers'. If only the DOTS gateway server component (client-facing-side) is all= owed to generate the client-identifier (for possible onward forwarding), th= is gets around this issue as it is only the DOTS server component who is al= lowed to do the generation. [Jon1] In my implementation the DOTS server (gateway or not) always generat= es a client-identifier (will be changed if there already is a unique identi= fier following this discussion) which is associated with a mitigation-id et= c. so that the DOTS server can differentiate between the same mitigation-id= from different clients. [Med] Ok, thanks. This is an optional attribute. 2nd change: Delete this text because client-identifier is uniquely assigned= by the first server-side gateway; there is no need to prepend identifiers = computed by other gateways. OLD: If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list. [Jon1] OK Comments and modifications are more welcome. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : lundi 18 d=E9cembre 2017 13:28 =C0 : Jon Shallow; dots@ietf.org; kaname nishizuka Objet : Re: [Dots] client-identifier: Recurisve signaling & Aggregation Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 18 d=E9cembre 2017 11:40 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kanam= e nishizuka Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med / Kaname, "I propose making it "MUST NOT": The client-identifier attribute MUST NOT be generated and included by the DOTS client." We do need to handle the case of a broken client (how does the DOTS server = know it is a DOTS gateway client or a real DOTS client?) who does not obey = the MUST. [Med] ...but broken clients may communicate directly with servers without a= ny gateway on the path. "The client-identifier attribute SHOULD NOT be generated and included by th= e DOTS client. If a client-identifier was generated by the DOTS client, the= DOTS gateway MUST update the value with zero probability of the same value= among different DOTS clients." Is the safer option for me. [Med] Actually, =B7 (R1) we do need MUST so that as a general rule clients do not i= nsert a client-id parameter in their requests. =B7 And (R2) DOTS servers MUST ignore client-ids that are supplied = by the origin DOTS clients. In deployments without gateways, client-ids supplied by broken DOTS clients= will be ignored by the server as per R2. In deployments with gateways, the first server-side gateway will follow R2 = and strip any value supplied by the client. If we add text to cover (R2), I don't think we need a sentence about updati= ng the content because client-id is a value that is ***assigned*** exclusiv= ely by a dots gateway: The 'client-identifier' value MUST be assigned by the DOTS gateway ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in a manner that ensures that there is zero probability that the same value will be assigned to a different DOTS client. Otherwise, see [Jon] inline (8 times). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 18 December 2017 06:59 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Jon, Thank you for sharing your thoughts. Please see comments inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : samedi 16 d=E9cembre 2017 21:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] client-identifier: Recurisve signaling & Aggregation Hi Med and all, I think that 'gateway-identifier' is likely to cause more confusion and wil= l not actually help to try and solve what I perceive is the underlying issu= e that has triggered this discussion - "How do we handle 'client-identifier= s' when a DOTS gateway does aggregation?" [Med] There are also some complications even when no aggregation is in use.= See below. . I am leaning towards your Option 2. Some of my reasoning is below. Background to client-identifiers. In the general case (e.g. no DOTS gateway aggregation of filters / aliases = etc.), every time a request or update (both signal and data) passes upstrea= m through a DOTS gateway, an additional 'client-identifier' is added to the= request / update. The final DOTS server can then uniquely identify the re= quest / update as coming from a specific Client and exactly match, say, an = (possibly non unique alias-name) alias definition sent over the data channe= l with a (possibly non unique mitigation-id) mitigation request using the s= ame alias-name sent over the signal channel. Client Identification Usage Example DOTS client (C1aj) ------------------------------------- (S1j) DOTS gateway= J (C2j) ----------\ DOTS client (C1bj) ----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway= K (C3k) -------- (S3) DOTS client (C1bx) --------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) -------/ DOTS client (C1by) --------/ Where CI is 'client-identifier' - a unique hash of the client identificatio= n :- C1ax does a PUT [alias-name=3DServer1], C2x does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)], C3k does a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)] and then S3 uniquely stores this alias-name as [alias-name=3DServer1&client= -identifer=3DCI(C1ax),CI(C2x),CI(C3k)] [Med] This assumes that the DOTS forwarding path will always be the same (t= hat is, the same set of gateways will be solicited for requests coming from= a given DOTS client). [Jon] The current text states "If the 'client-identifier' value is already = present in the mitigation request received from the DOTS client, the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed 'client-identifier' value to the end of the 'client- identifier' list." [Jon] The MAY is not a MUST for the simple reason that if the original DOT= S client client-identifier is computed correctly, it should be unique all t= he way through the different DOTS gateways (so no additional client-identif= iers need to get added) so that S3 just sees [alias-name=3DServer1&client-i= dentifer=3DCI(C1ax)]. The DOTS gateways in the path can then change over t= ime with no issues. [Jon] All that is required then is that a DOTS gateway makes sure that any = Client-Identifiers are unique for all its clients (including clients behind= gateways) and so does not need to add in additional client-identifiers (bu= t still adds in the first one if the first DOTS gateway). [Med] Agree for the first server-side gateway. [Jon] NOTE: A DOTS gateway can elect to not add in any client-identifier - = even if it is the first in the chain if it wants to hide the client informa= tion, but this will potentially cause information differentiation issues at= the DOTS server and I would not recommend it as client-identifiers, if cre= ated properly, obfuscate the actual client information. [Med]I do see some implications of this design in a multi-homing scenario w= ith the same mitigation provider: the same request from a multi-homed DOTS = client will be presented to the server as being distinct requests...while t= his is not. It may be the same request that is forked among existent networ= k attachments or a request that is sent over a first link, but a subsequent= one over another link. [Jon] Perhaps I am missing something here, but I would be expecting a multi= -homed device to be using the same PKI certificate (or equivalent) in which= case the client-identifier (which is not IP based) would be the same over = the different network interfaces. [Med] I'm referring to this "[alias-name=3DServer1&client-identifer=3DCI(C1= ax),CI(C2x),CI(C3k)]". [Jon] If however, the different network interfaces are connected to differe= nt DOTS provider domains, then there will be multiple PKI certs, and hence = different client-identifiers propagating up to the DOTS servers - but as th= ese are different provider domains will they ever join up into a common dom= ain? If they do, then this is where you could be getting conflicting reque= sts - subject of another discussion. [Med] Sure, these are deployment-specific. My concern is to avoid design ch= oices that make hidden assumptions. [Med] Separating both client-id from gateway-id does not suffer from this i= ssue (even when no aggregation). [Jon] Yes - the assumption being that all the client-identifiers are unique= - In which case I argue again that additional information - e.g. gateway-i= dentifiers are irrelevant (and also are useless when there are multiple pat= hs through the DOTS gateways as you refer to above). [Med] If we agree that one (unique) client-id is supplied, then I'm fine. so that if any of the DOTS clients do a PUT [alias-name=3DServer1] (with sa= me alias name) S3 can differentiate them all based on the different CI(). Then when C1ax requests a mitigation with alias-name=3DServer1, by the time= the request gets to S3, S3 can match the alias-name definition in the miti= gate request with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax)= ,CI(C2x),CI(C3k)]. If C1aj also requests a mitigation with alias-name=3DServer1, S3 will see t= he alias-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)]= and match accordingly. As responses come back from S3 to the originating client, the appropriate C= I(cxxx) gets stripped off so the originating client sees no 'client-identif= ier' fields at all. This general solution is simple with only one disadvantage - there is a lim= it of 20 - 24 client-identifiers (20 - 24 DOTS gateways) that will fit into= a single UDP packet due to MTU restrictions. However in practice there ar= e unlikely to be this number of DOTS gateways. The count varies based on h= ow much other information needs to be put into the packet. DOTS Gateway Session aggregation There is no reason as to why multiple DOTS clients' signal and data request= s cannot be multiplexed into a single session on the DOTS gateway to DOTS s= erver connection - especially as different client-identifiers separate out = the different requests / responses. This session aggregation is not the same as signal / data aggregation NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (whic= h may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation [Med] Agree. DOTS Gateway signal / data aggregation challenges Individual clients in general will generate their unique mitigation request= s - but may have common information (e.g. same protocol, ports, alias-name)= . If the mitigation requests are not unique then we have potential conflic= ts - not part of this discussion. Aggregating (unique) mitigation requests on a DOTS gateway could be a progr= ammatic challenge, unless it is the simple aggregation of all the different= target-prefixes - aggregating different port requirements for different ta= rget-prefixes gets more interesting..... This adds in a lot of potential c= omplexity with potential for boundary condition error issues. Aggregation of Filters is at first sight relatively simple - but there then= may be ordering challenges / conflicts - e.g. one filter has an IP that is= a white-list, and another has the same IP as a black-list - both valid in = the respective client environment. Ordering of conflicting filter informat= ion is important and I am not sure that a DOTS gateway will do this proper= ly unless it either has some hints or complex rules to work with - just add= ing in complexity where more things can potentially go wrong. Use of gateway-identifier and client-identifier combination can be used to = partially resolve some of the challenges (e.g. list of client-identifiers t= hat are allowed to use this aggregated filter rule), but again we are limit= ed to 20 - 24 *-identifiers in total due to packet MTU. Even if we for exa= mple say that there is a maximum of 4 DOTS gateways allowed, we then limit = the number of clients that can be aggregated to 16 - 20. Do we really want= to restrict the number of supported DOTS clients per DOTS gateway if aggre= gation is supported? [Med] I guess you meant "restrict the number of aggregated clients per DOTS= gateway", not the "number of DOTS clients serviced by a DOTS gateway". I w= ould say this is deployment-specific. A deployment that enables signal/data= channel aggregation is aware of this limitation. [Jon] Yes, that is better phrasing. [Med] OK. I still struggle with how do you actually do the aggregation (merging of = data/signal) at any gateway other than in a couple of simple cases out of t= he many different scenarios. [Med] Please note that I used "good/bad deployment choices" in the initial = message. Merging the requests will induce some complexity at the gateway, s= ure. From a protocol standpoint, I'm trying to be neutral on this. My main = concern is to avoid making choices in the protocol that will have deploymen= t implications. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 15 December 2017 14:20 To: dots@ietf.org Subject: [Dots] client-identifier: Recurisve signaling & Aggregation Hi all, To avoid potential conflicts and also in order to help the server select th= e appropriate policy to enforce, signal/data channel protocol drafts specif= y a parameter called "client-identifier". The design allows this parameter = to carry multiple values. Putting aside the extensibility argument of the data model, the signal/data= channel protocol drafts are silent about the exact use of multiple values. The potential deployment cases for multiple values are (without making any = assumption whether these cases are good/bad deployment choices): (1)Multiple gateways may be on path. For example, draft-ietf-dots-architect= ure discusses recursive signaling and also cases where multiple DOTS gatewa= ys are involved. (2)Requests from multiple clients may be aggregated by the same server-side= into one single request forwarded to the upstream server. For example, fil= tering rules received from multiple clients of the same domain may be aggre= gated in one single request. The current approach has the merit to not make any assumption on the gatewa= y behavior (e.g., (2)), but it leads to a confusion. For example, a DOTS se= rver does not know whether multiple client-ids supplied in a messages refer= to multiple DOTS clients or to a DOTS client and a set of on-path gateways= . The protocol documents need to be updated to avoid such confusion. Two op= tions are listed below: Option 1 (Avoid making any assumption on gateways/proper semantic distincti= on between clients and on-path gateways) - Restrict the usage of 'client-identifier' to carry identifiers of clie= nts, not gateways. - On-path gateways may include a new parameter called 'gateway-identifie= r' to ease contexts retrieval and avoid potential collisions. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'gateway-identifier' pointing to G1 Option 2 (Describe what a gateway cannot do) - Update the architecture document to indicate that requests are not agg= regated by a dots gateway. - 'client-identifier' includes multiple values only and only if multiple= gateways are on-path. The order of the values is important because the fir= st one will be the one pointing to the source DOTS clients. An example is provided below: C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS G1 will update the request with 'client-identifier' pointing to C G2 will update the request with 'client-identifier' pointing to G1 (in addi= tion to C) We are seeking for feedback from the WG on which direction to take. Thoughts? Cheers, Med --_000_DM5PR16MB17883109E71C5F602FE25E55EA0F0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I donR= 17;t think the functionality of DOTS gateway needs to be complicated by agg= regating mitigation requests and forking responses. The drafts need to clar= ify that DOTS gateway only performs aggregation at session-level but not at the request-level.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, December 19, 2017 3:52 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org; ka= name nishizuka <kaname@nttv6.jp>
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 19 d=E9cembre 2017 10:57
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

“= [Med] I suspect the disconnect is caused = by mixing connectivity and DOTS control aspects”

&nbs= p;

Ahh ̵= 1; the light bulb has gone off – why our discussions had a disconnect= .  It is down to the interpretation of the word “side” as = used in “Client Side DOTS gateway”.  To you it meant ̶= 0;control or ownership”, to me “connectivity or position relative to DOTS gateway”.

[Med] Yes, indeed.

 <= /p>

&nbs= p;

To preven= t others getting confused, my suggestion would be to update the following i= n the various draft specs

&nbs= p;

“Cl= ient-Side DOTS Gateway” to “Client Domain Managed DOTS gateway&= #8221;

“Se= rver-Side DOTS Gateway” to “Server Domain Managed DOTS gateway&= #8221;

“DO= TS gateway server-side” to “DOTS gateway server-facing-sideR= 21;

“DO= TS gateway client-side” to “DOTS gateway client-facing-sideR= 21;

&nbs= p;

The latte= r 2 should be defined somewhere.

 <= /p>

[Med] I extracted this co= mment and sent it as a comment to the ongoing WGLC on the requirements I-D.= The signal channel/data channel drafts will be updated to reflect whatever change will be endorsed in the requirements I-= D.

&nbs= p;

To me, a = gateway is a border of some sort – where there is a potential discont= inuity of flow (e.g. aggregation, client/server etc.)

&nbs= p;

Otherwise= , see inline [Jon5].

&nbs= p;

Regards

&nbs= p;

Jon<= /o:p>

&n= bsp;

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 19 December 2017 07:15
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 17:29
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

See inl= ine [Jon4].  I have deleted some of the “see inline messagesR= 21;.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 14:54
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med,=

&n= bsp;

Going i= n the right direction, but see comments inline [Jon1].

&n= bsp;

As a si= de comment, I always have to think twice what “DOTS gateway server-si= de” actually means.  It actually means the DOTS client component logic of a DOTS gateway.  There is no definiti= on of terms in the signal channel draft, but the definition could perhaps b= e added to the dots requirements draft.  Others may also get confused = about this.  Perhaps “DOTS gateway server-facing-side” is clearer, even though much longer to type!

 <= /p>

[Med] We do have the foll= owing definition in the requirements I-D:

 <= /p>

    &nbs= p; Client-side DOTS gateways

    &nbs= p; are DOTS gateways that are in the DOTS client's domain, while=

    &nbs= p; server-side DOTS gateways denote DOTS gateways that are in the

    &nbs= p; DOTS server's domain.=

&n= bsp;

&n= bsp;

[Jon2] = Yes – actually, this adds to the confusion in my mind.  For a si= ngular DOTS gateway, it could have a client-facing-side that is in the DOTS= client domain, and a server-facing side that is in a different DOTS server domain.  The quoted text implies it is one= or the other, but not both.

[Med] Do you have a parti= cular case in mind in which we should allow for the “client-facing si= de” of a gateway to belong to the client domain and its “server-facing side” to belong to the server domain?

[Jon3]T= he recursive gateway comes immediately to mind – when an ISP cannot h= andle the current attack and wants to invoke someone else to handle it.&nbs= p; Otherwise to me, a gateway to me is either an aggregation point of clients within a common domain or a border between tw= o different domains.

[Med] Given that recursiv= e signalling is opaque to the origin DOTS client, all involved gateways are= IMHO at the server-side (from the perspective of the source client). The only difference is that the intermediate dots gate= way (server) is managed by Provider 1 while the final server is managed by = another provider.

[Jon4] = Hmm – I am not convinced.  Some of your examples below actually = give examples for a DOTS gateway sitting in both client and (different) ser= ver domains.

[Med] I suspect the disco= nnect is caused by mixing connectivity and DOTS control aspects.

[Jon5] = Thanks – this is the cause of our disconnect in interpretation of = 220;side” – well spotted

 <= /p>

&n= bsp;

[Jon2] = Also, being picky, does “Client-side DOTS gateway” (type of DOT= S gateway) actually mean the same as “DOTS gateway client-side”= (component within a DOTS gateway)?

[Med] No. Those are two d= istinct things/dimensions:

- =    “xxx-side DOTS gateway” means this is owned and operate= d by xxx.

- =    “DOTS gateway client-side” refers to the client-facing = interface of a DTOS gateway. It applies for both client- and server-side getaways.  

[Jon3] = I agree with your distinct definitions, but not the use of the definition i= n the requirements I-D to cover the definition of “DOTS Gateway clien= t-side”

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 13:04
To: Jon Shallow; dots@ietf.org;= kaname nishizuka
Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Jon,

 

Please see below two proposed changes to= hopefully conclude on the issues discussed in this thread:

 

1st change:

 

OLD:

   client-identifi= er:  The client identifier MAY be conveyed by the DOTS

    &nbs= p; gateway to propagate the DOTS client identity from the gateway's

    &nbs= p; client-side to the gateway's server-side, and from the gateway's

    &nbs= p; server-side to the DOTS server.  This allows the DOTS server to

    &nbs= p; accept mitigation requests with scopes which the DOTS client is

    &nbs= p;authorized to manage.

 

    &nbs= p; The 'client-identifier' value MUST be assigned by the DOTS gateway<= /o:p>

    &nbs= p; in a manner that ensures that there is zero probability that the

    &nbs= p; same value will be assigned to a different DOTS client.  The DOTS

    &nbs= p; gateway MUST conceal potentially sensitive DOTS client identity

    &nbs= p; information.  The client-identifier attribute SHOULD NOT be

    &nbs= p; generated and included by the DOTS client.

 

    &nbs= p; This is an optional attribute.

 

NEW:

   client-identifi= er:  The client identifier MAY be conveyed by a

    &nbs= p; server-side DOTS gateway to propagate the DOTS client identity

    &nbs= p; from the gateway's client-side to the gateway's server-side, and

    &nbs= p; from the gateway's server-side to the DOTS server. 'client-

    &nbs= p; identifier' MAY be used by the final DOTS server for policy

    &nbs= p; enforcement purposes.

 

    &nbs= p; The 'client-identifier' value MUST be assigned by the server-side

[Jon1]  Actually, as the client and server components of a DOTs gate= way are separate (the server-facing component has no real knowledge of what= is happening on the client-facing side), it needs to be the client-facing-side of the DOTS gateway that assigns the= (unique) client-identifier which is then passed over to the server-facing-= side for onward transmission.

 

[Med] You are ri= ght if we zoom on the internal implementation of a DOTS gateway. This part = of the text focuses on the external behavior of the DOTS gateway. The text does not need to zoom in given that the second = sentence above says;

 

[Jon2] In terms of helping the implementers, the use of only DOTS server = being allowed to generate a ‘client-identifier’ as discussed la= ter.  If “server-side” was removed as in :-

“client-identifier:  The client i= dentifier MAY be conveyed by a

      DOTS gateway to propagate the DOTS client = identity …”

Removes a lot of confusion in my mind.

 

[Med] The “= ;server-side” is important because we don’t want client-side GW= s to reveal the identity of internal dots clients.

[Jon3] Why do we need to be restrictive to “Server-side DOTS gatewa= ys” here?

[Med] For privac= y concerns: e.g., avoid revealing how/where DOTS clients are deployed in th= e client’s domain.<= /o:p>

[Jon4] But all this (deployment etc.) information is in the client domain= only using your definition of a client-side DOTS gateway – so within= the client space who the really cares?

[Jon4] But this information going into another domain is the security con= cern.  However, to get a mitigation request to go between domains, the= re has to be a border at some point.  How do we handle that?  What does the border look like (it cannot be a cl= ient-side or server-side DOTS gateway as that is not allowed to straddle do= mains as you assert)?

[Med] It looks l= ike what is described in the architecture draft: a gateway located in the s= erver-side.

 

    &nbs= p;            &= nbsp;      example.net domain

    &nbs= p;            &= nbsp;      . . . . . . . . . . . . . . . . .<= /o:p>

    &nbs= p;            &= nbsp;      .    Gn   = ;            &n= bsp;         .

    &nbs= p;     +----+    1   .=   +----+       +-----------&= #43;   .

    &nbs= p;     | Cc |<--------->| Sn |~~~~~~~| Mitigator = |   .

    &nbs= p;     +----+     &nbs= p;  .  +=3D=3D=3D=3D+      = |     Mn    |   .<= /span>

    &nbs= p;            &= nbsp;      .  | Cn |    &= nbsp;  +-----------+   .

    &nbs= p;   example.com     .  +----+&n= bsp;            = ;          .=

    &nbs= p;      client      = .    ^         = ;             &= nbsp;   .

    &nbs= p;            &= nbsp;      . . .|. . . . . . . . . . . . . .<= /o:p>

    &nbs= p;            &= nbsp;           |

    &nbs= p;            &= nbsp;         1 |=

    &nbs= p;            &= nbsp;           |

    &nbs= p;            &= nbsp;      . . .|. . . . . . . . . . . . . .<= /o:p>

    &nbs= p;            &= nbsp;      .    v   =             &nb= sp;          .

    &nbs= p;            &= nbsp;      .  +----+   = ;    +-----------+   .

    &nbs= p;            &= nbsp;      .  | So |~~~~~~~| Mitigator | = ;  .

    &nbs= p;            &= nbsp;      .  +----+ &nbs= p;     |     Mo    |=    .

  &nbs= p;            &= nbsp;        .    &n= bsp;          +-----------= +   .

  &nbs= p;            &= nbsp;        .    &n= bsp;            = ;            &n= bsp; .

  &nbs= p;            &= nbsp;        . . . . . . . . . . . . . .= . . .

  &nbs= p;            &= nbsp;        example.org domain

 

  &nbs= p;            &= nbsp;      Figure 13: Recursive Signaling

[Jon5] Note: It is possible that Cc actually is a gateway – which w= ould be client managed and is the border point

[Med] Yes, Cc ma= y a be “client-side DOTS gateway” or “Client Domain Manag= ed DOTS gateway” if you will :)

 

We do have this = text (that may be tweaked):

 

   In order to pre= vent leaking internal information outside a client-

   domain, DOTS ga= teways located in the client-domain SHOULD NOT reveal

   the identificat= ion information that pertains to internal DOTS clients

   (client-identif= ier) unless explicitly configured to do so.

[Jon4] I had always read this as being a DOTS gateway on the border of a = different client and server domain

[Med] The mentio= n which is important in that text is: “DOTS gateways located in the client-domain”.<= /span>

[Jon5] Agreed.  However, if there are multiple gateways in the chain= , all client managed, it is only the one on the border with a server domain= that needs to be extra careful.

 

 

[Jon3] “Client-side DOTS gateways” may, or may not, want to p= ass on “client-identifiers” (which are obfuscated to hide ident= ity).  If they do not pass on “client-identifiers” then th= e DOTS server they connect to (which is in the same domain by definition) wi= ll not be able to differentiate between the different clients – the w= hole purpose of “client-identifiers” – or am I missing so= mething here?

[Med] For client= -side DOTS gateways, the server does not need to rely upon the identity of = internal DOTS clients; the identity of the gw is sufficient. Imagine an enterprise network with multiple DOTS clients an= d a DOTS gateway located on the CPE that intercepts all messages from these= clients. The ultimate DOTS server does not to know about those DOTS client= s.

[Jon4] Again an example of a DOTS gateway that sits both in a client and = (different) server domain.

[Med] The CPE is= in the border from a connectivity standpoint, but for DOTS, the gateway is= under the control of the client. I don’t see the “server domain” part in this example.

[Jon5] Again a disconnect in our interpretation, now understood.  To= me the gateway (albeit it client managed) is the border between the client= and server domains.

[Med] Let’= s fix the wording to avoid confusion.

 

 

 

[Jon3] To me, the only time that “client-identifiers” may nee= d to be dropped (not that I recommend doing this) is when a DOTS Gateway is= sitting in both a client’s domain and a different server’s domain as a domain border gateway.

 

“to propagate the DOTS client identity from the gateway's

    &nbs= p; client-side to the gateway's server-side, and from the gateway's

    &nbs= p; server-side to the DOTS server. ”=

 

    &nbs= p; DOTS gateway in a manner that ensures that there is zero

    &nbs= p; probability that the same value will be assigned to a different

    &nbs= p; DOTS client.  The server-side DOTS gateway MUST conceal<= /span>

    &nbs= p; potentially sensitive DOTS client identity information.

 

    &nbs= p; If aggregating DOTS mitigation requests received from multiple

    &nbs= p; DOTS clients is enabled, the server-side DOTS gateway has to include

    &nbs= p; a list of 'client-identifier' values; each value is pointing to a

    &nbs= p; DOTS client.  It is out of scope of this document to specify how

[Jon1] I prefer “a list of 'client-identifier' values; each value i= s pointing to a unique

      DOTS client that is in the aggregated list= .  It is out of….”

 

[Med] Deal. &nbs= p;

 

    &nbs= p; aggregation is implemented by a DOTS gateway.

 

    &nbs= p; The client-identifier attribute MUST NOT be generated and included<= /o:p>

    &nbs= p; by DOTS clients.

 

    &nbs= p; DOTS servers MUST ignore client-identifier attributes that are

    &nbs= p; directly supplied by source DOTS clients.  This implies that first<= o:p>

    &nbs= p; server-side DOTS gateways MUST strip client-identifier attributes

    &nbs= p; supplied by DOTS clients.

[Jon1] How do we differentiate between an actual DOTS client and the clie= nt component of a DOTS gateway (i.e. server-facing-side) as seen by a DOTS = server?  There is nothing that I have spotted for this in the DOTS signal protocol.

 

[Med] I confirm,= there is no such text in the draft. A deployment would consist in explicit= ly configuring a list of gateways (ACLs) on the server; the server will trust client-id if and only if it is coming from a= server-side gateways in that list.

 

[Jon2] Then do we need to instruct the implementers of the signal channel= that this is what should be done?

[Med] What about= adding this text:

 

NEW:

    &nbs= p; DOTS servers MAY support a

    &nbs= p; configuration parameter (e.g., ACLs) to identify DOTS gateways

    &nbs= p; that are trusted to supply client-identifier attributes.

[Jon4] I do not think ACL is the right term here.  In the same way t= he a DOTS server needs to know the valid client IDs of the DOTS clients tha= t can use it (along with the valid target IP addresses etc.) “valid gateway” could be added in.  I = would just drop “(e.g. ACLS)”.

[Med] Dropped.

 

[Jon1] I do agree that true DOTS clients MUST NOT generate ‘client-= identifiers’. If only the DOTS gateway server component (client-facin= g-side) is allowed to generate the client-identifier (for possible onward forwarding), this gets around this issue as it is onl= y the DOTS server component who is allowed to do the generation.=

 

[Jon1] In my implementation the DOTS server (gateway or not) always gener= ates a client-identifier (will be changed if there already is a unique iden= tifier following this discussion) which is associated with a mitigation-id etc. so that the DOTS server can differ= entiate between the same mitigation-id from different clients.

[Med] Ok, thanks= .

 

    &nbs= p; This is an optional attribute.

 

2nd change: Delete this text = because client-identifier is uniquely assigned by the first server-side gat= eway; there is no need to prepend identifiers computed by other gateways.

 

OLD:

   If the 'client-= identifier' value is already present in the

   mitigation requ= est received from the DOTS client, the DOTS gateway

   MAY compute the= 'client-identifier' value, as discussed above, and

   add the compute= d 'client-identifier' value to the end of the 'client-

   identifier' list.

[Jon1] OK

 

Comments and modifications are more welc= ome.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 18 d=E9cembre 2017 13:28
=C0 : Jon Shallow; dots@ietf.o= rg; kaname nishizuka
Objet : Re: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 18 d=E9cembre 2017 11:40
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; kaname nishizuka
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = / Kaname,

&n= bsp;

“I propose making it "MUST NOT":
The client-identifier attribute MUST NOT be       generated and included by the DOTS client.&#= 8221;

We do n= eed to handle the case of a broken client (how does the DOTS server know it= is a DOTS gateway client or a real DOTS client?) who does not obey the MUS= T.

[Med] …but broken c= lients may communicate directly with servers without any gateway on the pat= h.

&n= bsp;

“= The client-identifier attribute SHOULD NOT be generated and included by the= DOTS client. If a client-identifier was generated by the DOTS client, the = DOTS gateway MUST update the value with zero probability of the same value among different DOTS clients.”

&n= bsp;

Is the = safer option for me.

 <= /p>

[Med] Actually,

=B7    &nb= sp;    (R1) we do need MUST so that as a general rule clients do not inser= t a client-id parameter in their requests.

=B7    &nb= sp;    And (R2) DOTS servers MUST ignore client-ids that are supplied by t= he origin DOTS clients.

 <= /p>

In deployments without ga= teways, client-ids supplied by broken DOTS clients will be ignored by the s= erver as per R2.

In deployments with gatew= ays, the first server-side gateway will follow R2 and strip any value suppl= ied by the client.

 <= /p>

If we add text to cover (= R2), I don’t think we need a sentence about updating the content beca= use client-id is a value that is ***assigned*** exclusively by a dots gateway:

 <= /p>

    &nbs= p; The 'client-identifier' value MUST be assigned by the DOTS gateway<= /o:p>

    &nbs= p;            &= nbsp;           &nbs= p;      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =  

    &nbs= p; in a manner that ensures that there is zero probability that the

    &nbs= p; same value will be assigned to a different DOTS client. 

 

Otherwi= se, see [Jon] inline (8 times).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 18 December 2017 06:59
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] client-identifier: Recurisve signaling & Agg= regation

 

Hi Jon,

 

Thank you for sharing your thoughts.

 

Please see comments inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : samedi 16 d=E9cembre 2017 21:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] client-identifier: Recurisve signaling &= Aggregation

 

Hi Med = and all,

&n= bsp;

I think= that ‘gateway-identifier’ is likely to cause more confusion an= d will not actually help to try and solve what I perceive is the underlying= issue that has triggered this discussion - “How do we handle ‘client-identifiers’ when a DOTS gateway does aggreg= ation?”<= /span>

[Med] There are also some= complications even when no aggregation is in use. See below.

 <= /p>

. = I am leaning towards your Option 2.  Some of my reasoning is below.

&n= bsp;

Back= ground to client-identifiers.

&n= bsp;

In the = general case (e.g. no DOTS gateway aggregation of filters / aliases etc.), = every time a request or update (both signal and data) passes upstream throu= gh a DOTS gateway, an additional ‘client-identifier’ is added to the request / update.  The final DOTS server can then uni= quely identify the request / update as coming from a specific Client and ex= actly match, say, an (possibly non unique alias-name) alias definition sent= over the data channel with a (possibly non unique mitigation-id) mitigation request using the same alias-name sen= t over the signal channel.

&n= bsp;

Client = Identification Usage Example

&n= bsp;

DOTS client (C1aj) -----= -------------------------------- (S1j) DOTS gateway J (C2j) ----------\&nbs= p; 

DOTS client (C1bj) -----= -----------------------------------/      &nb= sp;             = ;            &n= bsp; |

    =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp; |

DOTS client (C1ax) -----= (S1x) DOTS gateway X (C2x) ---- (S2k) DOTS gateway K (C3k) -------- (S3)&n= bsp;  

DOTS client (C1bx) -----= ---/            = ;            &n= bsp;      |     &nbs= p;            &= nbsp;            

    =             &nb= sp;            =             &nb= sp;            =      |       &n= bsp;            = ;             <= o:p>

DOTS client (C1ay) -----= (S1y) DOTS gateway Y (C2y) -------/      &nb= sp;            =              &n= bsp;

DOTS client (C1by) -----= ---/            = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;    

&n= bsp;

Where C= I is ‘client-identifier’ – a unique hash of the client id= entification :-

C1ax do= es a PUT [alias-name=3DServer1],

C2x doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax)],<= /span>

C3k doe= s a PUT [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x)]=

and the= n S3 uniquely stores this alias-name as [alias-name=3DServer1&client-id= entifer=3DCI(C1ax),CI(C2x),CI(C3k)]

 <= /p>

[Med] This assumes that t= he DOTS forwarding path will always be the same (that is, the same set of g= ateways will be solicited for requests coming from a given DOTS client).

&n= bsp;

[Jon] T= he current text states “If the 'client-identifier' value is already p= resent in the

   mitigation request received from the DOT= S client, the DOTS gateway

   MAY compute the 'client-identifier' valu= e, as discussed above, and

   add the computed 'client-identifier' val= ue to the end of the 'client-

 &= nbsp; identifier' list.”

&n= bsp;

[Jon]&n= bsp; The MAY is not a MUST for the simple reason that if the original DOTS = client client-identifier is computed correctly, it should be unique all the= way through the different DOTS gateways (so no additional client-identifiers need to get added) so that S3 just sees [= alias-name=3DServer1&client-identifer=3DCI(C1ax)].  The DOTS gatew= ays in the path can then change over time with no issues.=

&n= bsp;

[Jon] A= ll that is required then is that a DOTS gateway makes sure that any Client-= Identifiers are unique for all its clients (including clients behind gatewa= ys) and so does not need to add in additional client-identifiers (but still adds in the first one if the first DOTS gate= way).

[Med] Agree for the first= server-side gateway.

&n= bsp;

[Jon] N= OTE: A DOTS gateway can elect to not add in any client-identifier – e= ven if it is the first in the chain if it wants to hide the client informat= ion, but this will potentially cause information differentiation issues at the DOTS server and I would not recommend it as = client-identifiers, if created properly, obfuscate the actual client inform= ation.

 <= /p>

[Med]I do see some implications of this design in a multi-homing scenario with the same mitigation provider: the same request = from a multi-homed DOTS client will be presented to the server as being dis= tinct requests…while this is not. It may be the same request that is = forked among existent network attachments or a request that is sent over a first link, but a subsequent one over ano= ther link.

&n= bsp;

[Jon] P= erhaps I am missing something here, but I would be expecting a multi-homed = device to be using the same PKI certificate (or equivalent) in which case t= he client-identifier (which is not IP based) would be the same over the different network interfaces. 

[Med] I’m referring= to this “[alias-name=3DServer1&client-identifer=3DCI(C1ax),CI(C2x),CI(C3k)]”.

&n= bsp;

[Jon] I= f however, the different network interfaces are connected to different DOTS= provider domains, then there will be multiple PKI certs, and hence differe= nt client-identifiers propagating up to the DOTS servers – but as these are different provider domains will = they ever join up into a common domain?  If they do, then this is wher= e you could be getting conflicting requests – subject of another disc= ussion.

[Med] Sure, these are dep= loyment-specific. My concern is to avoid design choices that make hidden as= sumptions.  

 <= /p>

 <= /p>

[Med] Separating both client-id from gateway-id= does not suffer from this issue (even when no aggregation).   &n= bsp;

 

[Jon] Y= es – the assumption being that all the client-identifiers are unique = – In which case I argue again that additional information – e.g= . gateway-identifiers are irrelevant (and also are useless when there are multiple paths through the DOTS gateways as you refer to ab= ove).

[Med] If we agree that on= e (unique) client-id is supplied, then I’m fine.

&n= bsp;

so that= if any of the DOTS clients do a PUT [alias-name=3DServer1] (with same alia= s name) S3 can differentiate them all based on the different CI().

&n= bsp;

Then wh= en C1ax requests a mitigation with alias-name=3DServer1, by the time the re= quest gets to S3, S3 can match the alias-name definition in the mitigate re= quest with that of [alias-name=3DServer1&client-identifer=3DCI(C1ax),CI= (C2x),CI(C3k)].

&n= bsp;

If C1aj= also requests a mitigation with alias-name=3DServer1, S3 will see the alia= s-name as [alias-name=3DServer1&client-identifer=3DCI(C1aj),CI(C2j)] an= d match accordingly.

&n= bsp;

As resp= onses come back from S3 to the originating client, the appropriate CI(cxxx)= gets stripped off so the originating client sees no ‘client-identifi= er’ fields at all.

&n= bsp;

This ge= neral solution is simple with only one disadvantage – there is a limi= t of 20 - 24 client-identifiers (20 – 24 DOTS gateways) that will fit= into a single UDP packet due to MTU restrictions.  However in practice there are unlikely to be this number of DOTS gateways.=   The count varies based on how much other information needs to be put= into the packet.

&n= bsp;

DOTS= Gateway Session aggregation

&n= bsp;

There i= s no reason as to why multiple DOTS clients’ signal and data requests= cannot be multiplexed into a single session on the DOTS gateway to DOTS se= rver connection – especially as different client-identifiers separate out the different requests / responses.

&n= bsp;

This se= ssion aggregation is not the same as signal / data aggregation

&n= bsp;

NOTE: i= etf-dots-architecture Figure 7, 8, 9 and 10 should really read (which may b= e where some of the confusion comes in)

Figure = 7: Client-Side Gateway with session Aggregation

Figure = 8: Client-Side Gateway without session Aggregation

Figure = 9: Server-Side Gateway with session Aggregation

Figure = 10: Server-Side Gateway without session Aggregation

&nbs= p;

[Med] Agree.

&n= bsp;

DOTS= Gateway signal / data aggregation challenges

&n= bsp;

Individ= ual clients in general will generate their unique mitigation requests ̵= 1; but may have common information (e.g. same protocol, ports, alias-name).=   If the mitigation requests are not unique then we have potential conflicts – not part of this discussion.=

&n= bsp;

Aggrega= ting (unique) mitigation requests on a DOTS gateway could be a programmatic= challenge, unless it is the simple aggregation of all the different target= -prefixes – aggregating different port requirements for different target-prefixes gets more interesting…..&= nbsp; This adds in a lot of potential complexity with potential for boundar= y condition error issues.

&n= bsp;

Aggrega= tion of Filters is at first sight relatively simple - but there then may be= ordering challenges / conflicts – e.g. one filter has an IP that is = a white-list, and another has the same IP as a black-list – both valid in the respective client environment. = ; Ordering of conflicting filter information is important  and I am no= t sure that a DOTS gateway will do this properly unless it either has some = hints or complex rules to work with – just adding in complexity where more things can potentially go wrong.

&n= bsp;

Use of = gateway-identifier and client-identifier combination can be used to partial= ly resolve some of the challenges (e.g. list of client-identifiers that are= allowed to use this aggregated filter rule), but again we are limited to 20 – 24 *-identifiers in total du= e to packet MTU.  Even if we for example say that there is a maximum o= f 4 DOTS gateways allowed, we then limit the number of clients that can be = aggregated to 16 – 20.  Do we really want to restrict the number of supported DOTS clients per DOTS gateway if aggregat= ion is supported?

 <= /p>

[Med] I guess you meant &= #8220;restrict the number of aggregated clients per DOTS gateway”, no= t the “number of DOTS clients serviced by a DOTS gateway”. I would say this is deployment-specific. A deployment that enables signal/da= ta channel aggregation is aware of this limitation.

&n= bsp;

[Jon] Y= es, that is better phrasing.

[Med] OK.

 <= /p>

  = I still struggle with how do you actually do the aggregation (merging of da= ta/signal) at any gateway other than in a couple of simple cases out of the= many different scenarios.

[Med] Please note that I = used “good/bad deployment choices” in the initial message. Merging the requests will induce some complexity a= t the gateway, sure. From a protocol standpoint, I’m trying to be neu= tral on this. My main concern is to avoid making choices in the protocol th= at will have deployment implications.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 15 December 2017 14:20
To: dots@ietf.org
Subject: [Dots] client-identifier: Recurisve signaling & Aggrega= tion

 

Hi all,

 

To avoid potential conflicts and also in order to he= lp the server select the appropriate policy to enforce, signal/data channel= protocol drafts specify a parameter called “client-identifier”= . The design allows this parameter to carry multiple values.

 

Putting aside the extensibility argument of the data= model, the signal/data channel protocol drafts are silent about the exact = use of multiple values.

 

The potential deployment cases for multiple values a= re (without making any assumption whether these cases are good/bad deployme= nt choices):

 

(1)Multiple gateways may be on path. For example, draft-ietf-dots-architecture discuss= es recursive signaling and also cases where multiple DOTS gateways are invo= lved.

(2)Requests from multiple clients may be aggregated by the same server-side into one s= ingle request forwarded to the upstream server. For example, filtering rule= s received from multiple clients of the same domain may be aggregated in on= e single request.   

 

The current approach has the merit to not make any a= ssumption on the gateway behavior (e.g., (2)), but it leads to a confusion.= For example, a DOTS server does not know whether multiple client-ids supplied in a messages refer to multiple DOTS clients = or to a DOTS client and a set of on-path gateways. The protocol documents n= eed to be updated to avoid such confusion. Two options are listed below:

 

Option 1 (Avoid making any assumption on gateways/pr= oper semantic distinction between clients and on-path gateways)<= /span>

-    Restrict the usage = of ‘client-identifier’ to carry identifiers of clients, not gat= eways.

-    On-path gateways ma= y include a new parameter called ‘gateway-identifier’ to ease c= ontexts retrieval and avoid potential collisions.

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with ‘client-identi= fier’ pointing to C

G2 will update the request with ‘gateway-ident= ifier’ pointing to G1

 

Option 2 (Describe what a gateway cannot do)

-    Update the architec= ture document to indicate that requests are not aggregated by a dots gatewa= y.

-    ‘client-ident= ifier’ includes multiple values only and only if multiple gateways ar= e on-path. The order of the values is important because the first one will be the one pointing to the source DOTS clients. =

 

An example is provided below:

 

C=3D=3D=3D=3D=3DG1=3D=3D=3D=3DG2=3D=3D=3D=3DS

 

G1 will update the request with ‘client-identi= fier’ pointing to C

G2 will update the request with ‘client-identi= fier’ pointing to G1 (in addition to C)

 

We are seeking for feedback from the WG on which dir= ection to take.

 

Thoughts?

 

Cheers,

Med

 

 

 <= /span>

--_000_DM5PR16MB17883109E71C5F602FE25E55EA0F0DM5PR16MB1788namp_-- From nobody Tue Dec 19 03:14:13 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C226127978 for ; Tue, 19 Dec 2017 03:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBjbPqg0th9i for ; Tue, 19 Dec 2017 03:14:08 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A033127871 for ; Tue, 19 Dec 2017 03:14:08 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 9506D602A2; Tue, 19 Dec 2017 12:14:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 79D7D8006E; Tue, 19 Dec 2017 12:14:06 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 12:14:06 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel Heartbeats Thread-Index: AQGht6CjVFygIRhvgE++pwgRVUADvAFJBRQ9o6OuIqCAAAnpQA== Date: Tue, 19 Dec 2017 11:14:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> In-Reply-To: <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09AAF3OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:14:11 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09AAF3OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 19 d=E9cembre 2017 11:49 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Signal Channel Heartbeats Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:02 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats Hi Jon, Thank you for initiating this thread. This is exactly the discussion I want= ed to have. The initial requirement that motivated introducing config-interval was the = following from the requirements I-D: When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Also, given that configuration changes may occur at the server, clients wil= l continue using stale configuration data retrieved previously from the ser= ver because there is no procedure to refresh the config. This is undesirabl= e. config-interval solves this. Of course, DOTS agents may decide to disabl= e the refresh procedure by setting it to 0 or by not returning the paramete= r. [Jon] I agree there may be stale signal configurations (most likely to occu= r during initial set-up and tuning) and "config-interval" will handle this.= The requirements I-D refer to this only being done when 'no mitigation req= uest is active'. The peacetime/attack (with possibly) alternative heartbea= t configurations partially handle this requirement as well. [Med] Agree. Having distinct heartbeat values (peacetime/attack) is an option, but it do= es not address the issue of stale configuration. Note that, for example, a = distinct max-retransmit may also be configured for peace time. The following would meet all the requirements: +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 [Jon] A minor comment - is the following more logical and more descriptive= ? [Med] I considered this but favored the other one because it is more compac= t. For example, when the same config is to be used for both peace/attack ti= mes, you just need to omit "peace-time-config", while you need to include t= he same value twice for the other proposal. Do you have a strong preference= ? +--:(configuration) +--rw session-id int32 +--rw attack-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw peace-time-config? | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw config-interval? int32 =B7 If no peace-time-config is provided, the same values will be us= ed for both peace and attack times till a change occurs. This is what is cu= rrently in the draft. =B7 peace-time-config may be returned to specify values to be used = for peacetime. Switching between attack/peace time parameter values will be= automatic. [Jon] We just need to make sure the 'automatic' switching is defined in the= text as well as updating CBOR mappings etc. [Jon] How do we handle in the YANG definition the fact that, say, when doin= g a GET, heartbeat-interval is "heartbeat-interval":{"current-value":xx,"mi= n-value":yy,"max-value":zz}, but a PUT currently is {"heartbeat-interval":a= a}. I think actually the PUT should be {"heartbeat-interval":{"current-val= ue":aa} and the YANG definition updated accordingly. [Med] A config parameter in the PUT implicitly means "current value". Is th= ere a benefit in saying it explicitly? I don't think so. No? Your point (A) makes sense to me. What about adding the following: NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. [Jon] Works for me [Med] Great! I do fully agree that consistent setting of the parameters is important. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats Hi there, There has been a lot of discussion on this, culminating in an update in dra= ft-ietf-dots-signal-channel-13 where 'config-interval' has been added in to= try to handle the different concerns. >From my trying to simplify things perspective:- 1. NAT devices usually allow outbound session requests (source IP nat'ing) = and allow for a response to come back within a defined time frame (lots of = discussion on this time frame - eventually setting on 30 seconds as a good = compromise - but could be longer). 2. NAT devices may be configured to allow inbound session requests (port re= direction) and allow for a response to come back within a defined time fram= e. Doing this does raise security policy issues as this potentially allows= uncontrolled access from the Internet to an internal device. 3. NAT devices are likely to break any server initiated heartbeats if the s= erver request frequency is longer than a NAT session is maintained in the N= AT device, and inbound session requests are disabled (for security reasons)= . 4. The frequency of Heartbeats ideally are different between peace time and= attack. In peace time there could be no heartbeats or at a slow rate to k= eep the signal channel alive. In attack time, 30 seconds appears to be the= agreed compromise time, but this is also influenced by the underlying COAP= protocol (retry intervals and counters etc.). In attack time, the rate s= hould be sufficient to detect any transmission issues within a reasonable t= ime frame. 5. For DOTS clients, there should be no issues with heartbeats going throug= h NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. 6. For DOTS servers dropping the heartbeat rate below that of the active NA= T session time will cause issues if there is a NAT device that does not all= ow inbound initiated sessions. 7. If heartbeats are in use, then both DOTS server and DOTS client have to = do their separate heartbeats for network connectively / DOTS agent availabi= lity. 8. If heartbeats are being used, the DOTS server can optionally trigger mit= igation is heartbeats stop working To give the ability to change the heartbeat rates, 'config-interval' has be= en added to the signal draft. A client then knows when to re-request the c= onfiguration (e.g. for potentially changed heartbeat values). However, 'co= nfig-interval' has to be sufficiently large to not compete with the heartbe= at rate (if they both were for the same interval, then configuration update= requests would effectively be doing the same task as heartbeats!). But if= 'config-interval' is too large (signal draft-13 example has it as 24 minut= es) then it could take time for the heartbeat rate to get increased in atta= ck time (and if the config update response packet does not get through, it = will not get updated). I think 'config-interval' needs to be thought throu= gh further. I have 2 proposals here A. If the heartbeat frequency is below that of the NAT session inactive tim= eout, the DOTS client will always transmit the heartbeats at the appropriat= e frequency. When the heartbeat request arrives at the DOTS server, this t= riggers a heartbeat process on the DOTS server to then heartbeat test the D= OTS client. Thus the DOTS server can use the "warm" NAT session during pea= cetime. If the heartbeat requests do not come in from the DOTS client (and= a peacetime heartbeat rate is configured) then auto-mitigation can get inv= oked if required. B. There are defined two heartbeat rates - one for when one or more mitigat= ion requests are in progress (attack situations) and a second rate for peac= e time (can be 0 (no heartbeats) or some long timeout). Whenever the first= mitigation is requested over a DOTS session, both ends start heart-beating= at the "attack" rate. This gets rid of any potential 'config-interval' r= efresh delays / 'new heartbeat interval' packets getting lost. When there = are no more mitigations active for that DOTS session, then the DOTS session= drops immediately back into the peacetime values. 'config-interval' could= then be replaced with 'peace-time-heartbeat-interval'. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A09AAF3OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 19 d=E9cembre 2017 11:49
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Signal Channel Heartbeats<= /p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 19 December 2017 10:02
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal Channel Heartbeats

 

Hi Jon,

 

Thank you for initiating this t= hread. This is exactly the discussion I wanted to have.

 

The initial requirement that mo= tivated introducing config-interval was the following from the requirements= I-D:

 

   &= nbsp;  When DOTS agents are exchanging heartbeats and no

   &= nbsp;  mitigation request is active, either agent MAY request changes = to

   &= nbsp;  the heartbeat rate.  For example, a DOTS server might want= to

   &= nbsp;  reduce heartbeat frequency or cease heartbeat exchanges when an=

   &= nbsp;  active DOTS client has not requested mitigation, in order to

   &= nbsp;  control load.

 

Also, given that configuration = changes may occur at the server, clients will continue using stale configur= ation data retrieved previously from the server because there is no procedure to refresh the config. This is undesirable. = config-interval solves this. Of course, DOTS agents may decide to disable t= he refresh procedure by setting it to 0 or by not returning the parameter.<= /span>

[Jon] I= agree there may be stale signal configurations (most likely to occur durin= g initial set-up and tuning) and “config-interval” will handle = this. The requirements I-D refer to this only being done when ‘no mitigation request is active’.  The peaceti= me/attack (with possibly) alternative heartbeat configurations partially ha= ndle this requirement as well.

[Med] Agree.

 

 

Having distinct heartbeat value= s (peacetime/attack) is an option, but it does not address the issue of sta= le configuration. Note that, for example, a distinct max-retransmit may also be configured for peace time.

 

The following would meet all th= e requirements:  

 

      &=
nbsp;   +--:(configuration)
      &=
nbsp;      +--rw session-id   &=
nbsp;        int32

      &=
nbsp;      +--rw heartbeat-interval? &nbs=
p; int16


      &=
nbsp;      +--rw missing-hb-allowed? &nbs=
p; int16


      &=
nbsp;      +--rw max-retransmit?  &n=
bsp;    int16


      &=
nbsp;      +--rw ack-timeout?   =
;       int16


      &=
nbsp;      +--rw ack-random-factor?  =
;  decimal64


      &=
nbsp;      +--rw trigger-mitigation? &nbs=
p; Boolean


      &=
nbsp;      +--rw peace-time-config<=
/span>


       =
      |   +--rw heartbeat-inter=
val?   int16


       =
      |   +--rw missing-hb-allo=
wed?   int16


      &=
nbsp;      |   +--rw max-retransmit?=
       int16


      &=
nbsp;      |   +--rw ack-timeout?&nb=
sp;         int16=



      &=
nbsp;      |   +--rw ack-random-fact=
or?    decimal64


      &=
nbsp;      +--rw config-interval?  &=
nbsp;   int32


[Jon]&n=
bsp; A minor comment – is the following more logical and more descrip=
tive?


[Med] I considered this but fav=
ored the other one because it is more compact. For example, when the same c=
onfig is to be used for both peace/attack times,
 you just need to omit “peace=
-time-config”, while you need to include
 the same value twice for the other proposal. Do you have a strong preferen=
ce? 



 


      &=
nbsp;   +--:(configuration)


      &=
nbsp;      +--rw session-id   &=
nbsp;        int32

      &=
nbsp;      +--rw attack-time-config=



      &=
nbsp;      |   +--rw heartbeat-inter=
val?   int16


      &=
nbsp;      |   +--rw missing-hb-allo=
wed?   int16


      &=
nbsp;      |   +--rw max-retransmit?=
       int16


      &=
nbsp;      |   +--rw ack-timeout?&nb=
sp;         int16=



      &=
nbsp;      |   +--rw ack-random-fact=
or?    decimal64


      &=
nbsp;      +--rw peace-time-config?=



       =
      |   +--rw heartbeat-inter=
val?   int16


       =
      |   +--rw missing-hb-allo=
wed?   int16


      &=
nbsp;      |   +--rw max-retransmit?=
       int16


      &=
nbsp;      |   +--rw ack-timeout?&nb=
sp;         int16=



      &=
nbsp;      |   +--rw ack-random-fact=
or?    decimal64


      &=
nbsp;      +--rw trigger-mitigation? &nbs=
p; Boolean


      &=
nbsp;      +--rw config-interval?  &=
nbsp;   int32


&n=
bsp;


=B7    &n=
bsp;   
If no peace-time-config=
 is provided, the same values will be used for both peace and attack times =
till a change occurs. This is what is currently
 in the draft. 


=B7    &n=
bsp;   
peace-time-config may b=
e returned to specify values to be used for peacetime. Switching between at=
tack/peace time parameter values will be automatic.


[Jon] W=
e just need to make sure the ‘automatic’ switching is defined i=
n the text as well as updating CBOR mappings etc.


&n=
bsp;


[Jon] H=
ow do we handle in the YANG definition the fact that, say, when doing a GET=
, heartbeat-interval is “heartbeat-interval”:{“current-va=
lue”:xx,”min-value”:yy,”max-value”:zz}, but a=
 PUT currently
 is {“heartbeat-interval”:aa}.  I think actually the PUT s=
hould be {“heartbeat-interval”:{“current-value”:aa}=
 and the YANG definition updated accordingly.


 


[Med] A config parameter in the=
 PUT implicitly means “current value”. Is there a benefit in sa=
ying it explicitly? I don’t think so. No?    


 


 


Your point (A) makes sense to m=
e. What about adding the following:


 


NEW:


   In order to avoid compli=
cations due to the presence of some stateful


   translators and firewall=
s (e.g., discard an incoming packet because


   no matching state is fou=
nd), DOTS servers MAY trigger their heartbeat


   requests immediately aft=
er receiving heartbeat probes from peer DOTS


   clients.


[Jon] Works for =
me


[Med] Great!


 


I do fully agree that consisten=
t setting of the parameters is important.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Jon Shallow

Envoy=E9 : lundi 18 d=E9cembre 2017 16:00

=C0 : dots@ietf.org

Objet : [Dots] Signal Channel Heartbeats






 


Hi there,


 


There has been a lot of discuss=
ion on this, culminating in an update in draft-ietf-dots-signal-channel-13 =
where ‘config-interval’ has been added in to try to handle the =
different concerns.


 


From my trying to simplify thin=
gs perspective:-


 


1. NAT devices usually allow ou=
tbound session requests (source IP nat’ing) and allow for a response =
to come back within a defined time frame (lots of discussion on this time f=
rame – eventually setting on 30 seconds as
 a good compromise – but could be longer).


 


2. NAT devices may be configure=
d to allow inbound session requests (port redirection) and allow for a resp=
onse to come back within a defined time frame.  Doing this does raise =
security policy issues as this potentially
 allows uncontrolled access from the Internet to an internal device.


 


3. NAT devices are likely to br=
eak any server initiated heartbeats if the server request frequency is long=
er than a NAT session is maintained in the NAT device, and inbound session =
requests are disabled (for security
 reasons).


 


4. The frequency of Heartbeats =
ideally are different between peace time and attack.  In peace time th=
ere could be no heartbeats or at a slow rate to keep the signal channel ali=
ve.  In attack time, 30 seconds appears to
 be the agreed compromise time, but this is also influenced by the underlyi=
ng COAP protocol  (retry intervals and counters etc.).  In attack=
 time, the rate should be sufficient to detect any transmission issues with=
in a reasonable time frame.


 


5. For DOTS clients, there shou=
ld be no issues with heartbeats going through NAT devices (other than durin=
g an attack where there may be packet loss) no matter what the heartbeat fr=
equency is.


 


6. For DOTS servers dropping th=
e heartbeat rate below that of the active NAT session time will cause issue=
s if there is a NAT device that does not allow inbound initiated sessions.<=
o:p>


 


7. If heartbeats are in use, th=
en both DOTS server and DOTS client have to do their separate heartbeats fo=
r network connectively / DOTS agent availability.


 


8. If heartbeats are being used=
, the DOTS server can optionally trigger mitigation is heartbeats stop work=
ing


 


To give the ability to change t=
he heartbeat rates, ‘config-interval’ has been added to the sig=
nal draft.  A client then knows when to re-request the configuration (=
e.g. for potentially changed heartbeat values).  However,
 ‘config-interval’ has to be sufficiently large to not compete =
with the heartbeat rate (if they both were for the same interval, then conf=
iguration update requests would effectively be doing the same task as heart=
beats!).  But if ‘config-interval’ is too large
 (signal draft-13 example has it as 24 minutes) then it could take time for=
 the heartbeat rate to get increased in attack time (and if the config upda=
te response packet does not get through, it will not get updated).  I =
think ‘config-interval’ needs to be thought
 through further.


 


I have 2 proposals here


 


A. If the heartbeat frequency i=
s below that of the NAT session inactive timeout, the DOTS client will alwa=
ys transmit the heartbeats at the appropriate frequency.  When the hea=
rtbeat request arrives at the DOTS server,
 this triggers a heartbeat process on the DOTS server to then heartbeat tes=
t the DOTS client.  Thus the DOTS server can use the “warm”=
; NAT session during peacetime.  If the heartbeat requests do not come=
 in from the DOTS client (and a peacetime heartbeat rate
 is configured) then auto-mitigation can get invoked if required.


 


B. There are defined two heartb=
eat rates – one for when one or more mitigation requests are in progr=
ess (attack situations) and a second rate for peace time (can be 0 (no hear=
tbeats) or some long timeout).  Whenever the
 first mitigation is requested over a DOTS session, both ends start heart-b=
eating at the “attack” rate.   This gets rid of any p=
otential ‘config-interval’ refresh delays / ‘new heartbea=
t interval’ packets getting lost.  When there are no more mitiga=
tions active
 for that DOTS session, then the DOTS session drops immediately back into t=
he peacetime values.  ‘config-interval’ could then be repl=
aced with ‘peace-time-heartbeat-interval’.

 


Regards


 


Jon


 


 
--_000_787AE7BB302AE849A7480A190F8B93300A09AAF3OPEXCLILMA3corp_-- From nobody Tue Dec 19 03:25:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B537E12D95E for ; Tue, 19 Dec 2017 03:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWGZz9mTfQqr for ; Tue, 19 Dec 2017 03:25:38 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8891612D87E for ; Tue, 19 Dec 2017 03:25:37 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513682736; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=E ruihxIayvL0QGydACv62Xng/cBsmrJyOGU9T3TrJ/ Y=; b=ZY77uR9qfETj3OWihW8d/eoA60xKAAyMYWK+ejwm2zLI e4AcH5KSUsQKHbXnEHjHDfGkjXJJIsQJg1L3i2cfm+R/hhWaoc reNHbvwhQgrI1ilvrf+7B6445CLPWlQUk7EJrVRm0dFoEXDeI7 Phw2r+c5aqsbrXmkYzvRKfDtsv8= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 0e1f_aefa_09e6ff27_1aae_4385_8dc7_c44a5f854b27; Tue, 19 Dec 2017 05:25:36 -0600 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 06:25:34 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 06:25:33 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 19 Dec 2017 06:25:33 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 06:25:31 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 11:25:31 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 11:25:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel Heartbeats Thread-Index: AdN4ENbheXtf5t9VRkK1cf1kUKfP+AAitvLAAAbTNoAAAN7sgAAACRvA Date: Tue, 19 Dec 2017 11:25:31 +0000 Message-ID: References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:+1a/io4yTje0DSYnKsiwXrjxKcju2pL8ikdtjC3U0tuPFiyXvFBtQvmAccbNny3TcgQwmeCjhwiDcK+a+Bhzk5WGUD0KXWl1FsIOeOQ9n5xlDmDFN7sO5LFBLJS2Ggouj740bAaI/Xcs4OYvYHHChkJqLDN0SL98XPB8psIRNqYdcwowkNHx7uYGI3LMsBbgcAqfekWViNBD791vcU77/xoYMwEphkluVSkJS5NogZltJVkGQJ62YNSTq4syAHngufJ8JQTQdboIBEIcfmXgv7PaJhZBrBSopbUK8Z6dOvJT5pCx8s4G3MFkenI78uHXirWn0SVgOG78U9wbl4MbmncaFqyRkyPjQUM1d/VM3bg=; 5:EkZW6Kjv8svm/xPlrTqpv2FQuuiOnYEMvuw3NWxOoNOY9FMrR0kyYDS31XpT5/UEVVDtCuiduqxL55w1Yut3+AOAiExGYt6ki6FQ+DI1bd8Cq346kOn82fX+v9TdqWVdQ98bcfiip354iZVzjCITP12w3Uk9pg0eMrt8lBHxlJM=; 24:yemXO1xO5WpGTWlQMfSKASWEVTERJeVz8KLkO9Wxsa79rbInSMETdTtPJY8WPbPYSH84DyEjE7KExu6x5GxfD8/dxNFXOL/JzM6CxINISpM=; 7:BIEcCJqkX0DaAM4gsnBeW6bJwKMN36YFFNbC2KTH+Vv4whb/kaNZZ7AlnPyhgQIxDCJzwwhP6yVT0XtvtazY9YX5M0DsNGfCJYdxMaqWhFS4+JePzwDXA3XCtg7Sim/0lfcrg25ZsXQLwLrJ/4jP3cvk2U+MWJWkJor9f31Fgg+VV6elSK2GqW5uj0uHFbrV6Iw4ImJ1EqsHX1ZHwh2Uq9GL3X9FejqrF/DhFYydJBK1uCLoxUS3UtW8zmDGzQQd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 741d63cd-8712-4a76-d0d1-08d546d336b6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(366004)(39860400002)(346002)(376002)(189003)(199004)(32952001)(15404003)(66066001)(8936002)(8676002)(14454004)(80792005)(2906002)(345774005)(7696005)(790700001)(6506007)(81166006)(86362001)(68736007)(110136005)(3660700001)(81156014)(53546011)(2950100002)(59450400001)(97736004)(3280700002)(5660300001)(99286004)(316002)(102836003)(6116002)(93886005)(3846002)(33656002)(2900100001)(9686003)(6246003)(25786009)(76176011)(236005)(72206003)(6306002)(53936002)(478600001)(561944003)(53946003)(19609705001)(229853002)(105586002)(106356001)(55016002)(7736002)(74316002)(77096006)(54896002)(2501003)(6436002)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887A83A02854FB0AC332AEEA0F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 741d63cd-8712-4a76-d0d1-08d546d336b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 11:25:31.1225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6182> : inlines <6262> : streams <1773561> : uri <2553762> Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:25:40 -0000 --_000_DM5PR16MB17887A83A02854FB0AC332AEEA0F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The CoAP messages for configuration update are marked as Confirmable, and a= re not suitable to be exchanged during attack time. It does not sound like = a good idea to modify the DOTS signal channel configuration parameters duri= ng attack time. I don't see the need for proposal (A) discussion below but = agree with the proposed updated yang model with attack-time-config and peac= e-time-config. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Tuesday, December 19, 2017 4:44 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 19 d=E9cembre 2017 11:49 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Signal Channel Heartbeats Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:02 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats Hi Jon, Thank you for initiating this thread. This is exactly the discussion I want= ed to have. The initial requirement that motivated introducing config-interval was the = following from the requirements I-D: When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Also, given that configuration changes may occur at the server, clients wil= l continue using stale configuration data retrieved previously from the ser= ver because there is no procedure to refresh the config. This is undesirabl= e. config-interval solves this. Of course, DOTS agents may decide to disabl= e the refresh procedure by setting it to 0 or by not returning the paramete= r. [Jon] I agree there may be stale signal configurations (most likely to occu= r during initial set-up and tuning) and "config-interval" will handle this.= The requirements I-D refer to this only being done when 'no mitigation req= uest is active'. The peacetime/attack (with possibly) alternative heartbea= t configurations partially handle this requirement as well. [Med] Agree. Having distinct heartbeat values (peacetime/attack) is an option, but it do= es not address the issue of stale configuration. Note that, for example, a = distinct max-retransmit may also be configured for peace time. The following would meet all the requirements: +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 [Jon] A minor comment - is the following more logical and more descriptive= ? [Med] I considered this but favored the other one because it is more compac= t. For example, when the same config is to be used for both peace/attack ti= mes, you just need to omit "peace-time-config", while you need to include t= he same value twice for the other proposal. Do you have a strong preference= ? +--:(configuration) +--rw session-id int32 +--rw attack-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw peace-time-config? | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw config-interval? int32 =B7 If no peace-time-config is provided, the same values will be us= ed for both peace and attack times till a change occurs. This is what is cu= rrently in the draft. =B7 peace-time-config may be returned to specify values to be used = for peacetime. Switching between attack/peace time parameter values will be= automatic. [Jon] We just need to make sure the 'automatic' switching is defined in the= text as well as updating CBOR mappings etc. [Jon] How do we handle in the YANG definition the fact that, say, when doin= g a GET, heartbeat-interval is "heartbeat-interval":{"current-value":xx,"mi= n-value":yy,"max-value":zz}, but a PUT currently is {"heartbeat-interval":a= a}. I think actually the PUT should be {"heartbeat-interval":{"current-val= ue":aa} and the YANG definition updated accordingly. [Med] A config parameter in the PUT implicitly means "current value". Is th= ere a benefit in saying it explicitly? I don't think so. No? Your point (A) makes sense to me. What about adding the following: NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. [Jon] Works for me [Med] Great! I do fully agree that consistent setting of the parameters is important. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats Hi there, There has been a lot of discussion on this, culminating in an update in dra= ft-ietf-dots-signal-channel-13 where 'config-interval' has been added in to= try to handle the different concerns. >From my trying to simplify things perspective:- 1. NAT devices usually allow outbound session requests (source IP nat'ing) = and allow for a response to come back within a defined time frame (lots of = discussion on this time frame - eventually setting on 30 seconds as a good = compromise - but could be longer). 2. NAT devices may be configured to allow inbound session requests (port re= direction) and allow for a response to come back within a defined time fram= e. Doing this does raise security policy issues as this potentially allows= uncontrolled access from the Internet to an internal device. 3. NAT devices are likely to break any server initiated heartbeats if the s= erver request frequency is longer than a NAT session is maintained in the N= AT device, and inbound session requests are disabled (for security reasons)= . 4. The frequency of Heartbeats ideally are different between peace time and= attack. In peace time there could be no heartbeats or at a slow rate to k= eep the signal channel alive. In attack time, 30 seconds appears to be the= agreed compromise time, but this is also influenced by the underlying COAP= protocol (retry intervals and counters etc.). In attack time, the rate s= hould be sufficient to detect any transmission issues within a reasonable t= ime frame. 5. For DOTS clients, there should be no issues with heartbeats going throug= h NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. 6. For DOTS servers dropping the heartbeat rate below that of the active NA= T session time will cause issues if there is a NAT device that does not all= ow inbound initiated sessions. 7. If heartbeats are in use, then both DOTS server and DOTS client have to = do their separate heartbeats for network connectively / DOTS agent availabi= lity. 8. If heartbeats are being used, the DOTS server can optionally trigger mit= igation is heartbeats stop working To give the ability to change the heartbeat rates, 'config-interval' has be= en added to the signal draft. A client then knows when to re-request the c= onfiguration (e.g. for potentially changed heartbeat values). However, 'co= nfig-interval' has to be sufficiently large to not compete with the heartbe= at rate (if they both were for the same interval, then configuration update= requests would effectively be doing the same task as heartbeats!). But if= 'config-interval' is too large (signal draft-13 example has it as 24 minut= es) then it could take time for the heartbeat rate to get increased in atta= ck time (and if the config update response packet does not get through, it = will not get updated). I think 'config-interval' needs to be thought throu= gh further. I have 2 proposals here A. If the heartbeat frequency is below that of the NAT session inactive tim= eout, the DOTS client will always transmit the heartbeats at the appropriat= e frequency. When the heartbeat request arrives at the DOTS server, this t= riggers a heartbeat process on the DOTS server to then heartbeat test the D= OTS client. Thus the DOTS server can use the "warm" NAT session during pea= cetime. If the heartbeat requests do not come in from the DOTS client (and= a peacetime heartbeat rate is configured) then auto-mitigation can get inv= oked if required. B. There are defined two heartbeat rates - one for when one or more mitigat= ion requests are in progress (attack situations) and a second rate for peac= e time (can be 0 (no heartbeats) or some long timeout). Whenever the first= mitigation is requested over a DOTS session, both ends start heart-beating= at the "attack" rate. This gets rid of any potential 'config-interval' r= efresh delays / 'new heartbeat interval' packets getting lost. When there = are no more mitigations active for that DOTS session, then the DOTS session= drops immediately back into the peacetime values. 'config-interval' could= then be replaced with 'peace-time-heartbeat-interval'. Regards Jon --_000_DM5PR16MB17887A83A02854FB0AC332AEEA0F0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The CoAP = messages for configuration update are marked as Confirmable, and are not su= itable to be exchanged during attack time. It does not sound like a good id= ea to modify the DOTS signal channel configuration parameters during attack time. I= don’t see the need for proposal (A) discussion below but agree with = the proposed updated yang model with attack-time-config and peace-time-conf= ig.

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, December 19, 2017 4:44 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] Signal Channel Heartbeats

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 19 d=E9cembre 2017 11:49
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Signal Channel Heartbeats<= /p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 19 December 2017 10:02
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal Channel Heartbeats

 

Hi Jon,

 

Thank you for initiating this thread. Th= is is exactly the discussion I wanted to have.

 

The initial requirement that motivated i= ntroducing config-interval was the following from the requirements I-D:

 

    &nbs= p; When DOTS agents are exchanging heartbeats and no

    &nbs= p; mitigation request is active, either agent MAY request changes to

    &nbs= p; the heartbeat rate.  For example, a DOTS server might want to<= /o:p>

    &nbs= p; reduce heartbeat frequency or cease heartbeat exchanges when an

    &nbs= p; active DOTS client has not requested mitigation, in order to<= /span>

    &nbs= p; control load.<= /p>

 

Also, given that configuration changes m= ay occur at the server, clients will continue using stale configuration dat= a retrieved previously from the server because there is no procedure to refresh the config. This is undesirable. config-i= nterval solves this. Of course, DOTS agents may decide to disable the refre= sh procedure by setting it to 0 or by not returning the parameter.

[Jon] I agree there ma= y be stale signal configurations (most likely to occur during initial set-u= p and tuning) and “config-interval” will handle this. The requi= rements I-D refer to this only being done when ‘no mitigation request is active’.  The peacetime/attack (with poss= ibly) alternative heartbeat configurations partially handle this requiremen= t as well.

[Med] Agree.

 

 

Having distinct heartbeat values (peacet= ime/attack) is an option, but it does not address the issue of stale config= uration. Note that, for example, a distinct max-retransmit may also be configured for peace time.

 

The following would meet all the require= ments:  

 

       &nbs=
p;  +--:(configuration)
       &nbs=
p;     +--rw session-id    &nbs=
p;       int32
       &nbs=
p;     +--rw heartbeat-interval?   int16<=
o:p>
       &nbs=
p;     +--rw missing-hb-allowed?   int16<=
o:p>
       &nbs=
p;     +--rw max-retransmit?    =
;   int16
       &nbs=
p;     +--rw ack-timeout?    &n=
bsp;     int16
       &nbs=
p;     +--rw ack-random-factor?    d=
ecimal64
       &nbs=
p;     +--rw trigger-mitigation?   Boolea=
n
       &nbs=
p;     +--rw peace-time-config

        &nb=
sp;    |   +--rw heartbeat-interval? =
;  int16


        &nb=
sp;    |   +--rw missing-hb-allowed? =
;  int16


        &nb=
sp;    |   +--rw max-retransmit? &nb=
sp;     int16


       &nbs=
p;     |   +--rw ack-timeout?  =
        int16


       &nbs=
p;     |   +--rw ack-random-factor? =
   decimal64


       &nbs=
p;     +--rw config-interval?   &nbs=
p;  int32


[Jon]  A minor co=
mment – is the following more logical and more descriptive?


[Med] I considered this but favored the =
other one because it is more compact. For example, when the same config is =
to be used for both peace/attack times, you just
 need to omit “peace-time-config”, while you need to include the same value twice
 for the other proposal. Do you have a strong preference? 


 


       &nbs=
p;  +--:(configuration)


       &nbs=
p;     +--rw session-id    &nbs=
p;       int32


       &nbs=
p;     +--rw attack-time-config

       &nbs=
p;     |   +--rw heartbeat-interval? =
;  int16


       &nbs=
p;     |   +--rw missing-hb-allowed? =
;  int16


       &nbs=
p;     |   +--rw max-retransmit? &nb=
sp;     int16


       &nbs=
p;     |   +--rw ack-timeout?  =
        int16


       &nbs=
p;     |   +--rw ack-random-factor? =
   decimal64


       &nbs=
p;     +--rw peace-time-config?

        &nb=
sp;    |   +--rw heartbeat-interval? =
;  int16


        &nb=
sp;    |   +--rw missing-hb-allowed? =
;  int16


        &nb=
sp;    |   +--rw max-retransmit? &nb=
sp;     int16


       &nbs=
p;     |   +--rw ack-timeout?  =
        int16


       &nbs=
p;     |   +--rw ack-random-factor? =
   decimal64


       &nbs=
p;     +--rw trigger-mitigation?   Boolea=
n


       &nbs=
p;     +--rw config-interval?   &nbs=
p;  int32


 


=B7       =
 
If no p=
eace-time-config is provided, the same values will be used for both peace a=
nd attack times till a change occurs. This is
 what is currently in the draft. 


=B7       =
 
peace-t=
ime-config may be returned to specify values to be used for peacetime. Swit=
ching between attack/peace time parameter values
 will be automatic.


[Jon] We just need to =
make sure the ‘automatic’ switching is defined in the text as w=
ell as updating CBOR mappings etc.


 


[Jon] How do we handle=
 in the YANG definition the fact that, say, when doing a GET, heartbeat-int=
erval is “heartbeat-interval”:{“current-value”:xx,&=
#8221;min-value”:yy,”max-value”:zz}, but a PUT currently =
is {“heartbeat-interval”:aa}. 
 I think actually the PUT should be {“heartbeat-interval”:{R=
20;current-value”:aa} and the YANG definition updated accordingly.


 


[Med] A config parameter in the PUT impl=
icitly means “current value”. Is there a benefit in saying it e=
xplicitly? I don’t think so. No?    =



 


 


Your point (A) makes sense to me. What a=
bout adding the following:


 


NEW:


   In order to avoid complications d=
ue to the presence of some stateful


   translators and firewalls (e.g., =
discard an incoming packet because


   no matching state is found), DOTS=
 servers MAY trigger their heartbeat


   requests immediately after receiv=
ing heartbeat probes from peer DOTS


   clients.


[Jon=
] Works for me


[Med] Great!


 


I do fully agree that consistent setting=
 of the parameters is important.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Jon Shallow

Envoy=E9 : lundi 18 d=E9cembre 2017 16:00

=C0 : dots@ietf.org

Objet : [Dots] Signal Channel Heartbeats






 


Hi there,


 


There has been a lot of discuss=
ion on this, culminating in an update in draft-ietf-dots-signal-channel-13 =
where ‘config-interval’ has been added in to try to handle the =
different concerns.


 


From my trying to simplify thin=
gs perspective:-


 


1. NAT devices usually allow ou=
tbound session requests (source IP nat’ing) and allow for a response =
to come back within a defined time frame (lots of discussion on this time f=
rame – eventually setting on 30 seconds as
 a good compromise – but could be longer).


 


2. NAT devices may be configure=
d to allow inbound session requests (port redirection) and allow for a resp=
onse to come back within a defined time frame.  Doing this does raise =
security policy issues as this potentially
 allows uncontrolled access from the Internet to an internal device.


 


3. NAT devices are likely to br=
eak any server initiated heartbeats if the server request frequency is long=
er than a NAT session is maintained in the NAT device, and inbound session =
requests are disabled (for security
 reasons).


 


4. The frequency of Heartbeats =
ideally are different between peace time and attack.  In peace time th=
ere could be no heartbeats or at a slow rate to keep the signal channel ali=
ve.  In attack time, 30 seconds appears to
 be the agreed compromise time, but this is also influenced by the underlyi=
ng COAP protocol  (retry intervals and counters etc.).  In attack=
 time, the rate should be sufficient to detect any transmission issues with=
in a reasonable time frame.


 


5. For DOTS clients, there shou=
ld be no issues with heartbeats going through NAT devices (other than durin=
g an attack where there may be packet loss) no matter what the heartbeat fr=
equency is.


 


6. For DOTS servers dropping th=
e heartbeat rate below that of the active NAT session time will cause issue=
s if there is a NAT device that does not allow inbound initiated sessions.<=
o:p>


 


7. If heartbeats are in use, th=
en both DOTS server and DOTS client have to do their separate heartbeats fo=
r network connectively / DOTS agent availability.


 


8. If heartbeats are being used=
, the DOTS server can optionally trigger mitigation is heartbeats stop work=
ing


 


To give the ability to change t=
he heartbeat rates, ‘config-interval’ has been added to the sig=
nal draft.  A client then knows when to re-request the configuration (=
e.g. for potentially changed heartbeat values).  However,
 ‘config-interval’ has to be sufficiently large to not compete =
with the heartbeat rate (if they both were for the same interval, then conf=
iguration update requests would effectively be doing the same task as heart=
beats!).  But if ‘config-interval’ is too large
 (signal draft-13 example has it as 24 minutes) then it could take time for=
 the heartbeat rate to get increased in attack time (and if the config upda=
te response packet does not get through, it will not get updated).  I =
think ‘config-interval’ needs to be thought
 through further.


 


I have 2 proposals here


 


A. If the heartbeat frequency i=
s below that of the NAT session inactive timeout, the DOTS client will alwa=
ys transmit the heartbeats at the appropriate frequency.  When the hea=
rtbeat request arrives at the DOTS server,
 this triggers a heartbeat process on the DOTS server to then heartbeat tes=
t the DOTS client.  Thus the DOTS server can use the “warm”=
; NAT session during peacetime.  If the heartbeat requests do not come=
 in from the DOTS client (and a peacetime heartbeat rate
 is configured) then auto-mitigation can get invoked if required.


 


B. There are defined two heartb=
eat rates – one for when one or more mitigation requests are in progr=
ess (attack situations) and a second rate for peace time (can be 0 (no hear=
tbeats) or some long timeout).  Whenever the
 first mitigation is requested over a DOTS session, both ends start heart-b=
eating at the “attack” rate.   This gets rid of any p=
otential ‘config-interval’ refresh delays / ‘new heartbea=
t interval’ packets getting lost.  When there are no more mitiga=
tions active
 for that DOTS session, then the DOTS session drops immediately back into t=
he peacetime values.  ‘config-interval’ could then be repl=
aced with ‘peace-time-heartbeat-interval’.

 


Regards


 


Jon


 


 
--_000_DM5PR16MB17887A83A02854FB0AC332AEEA0F0DM5PR16MB1788namp_-- From nobody Tue Dec 19 03:27:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729CC12DA68 for ; Tue, 19 Dec 2017 03:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvTPmGaR4-lH for ; Tue, 19 Dec 2017 03:27:14 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DB812DA4E for ; Tue, 19 Dec 2017 03:27:13 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRG3E-00052I-Bh; Tue, 19 Dec 2017 11:27:12 +0000 From: "Jon Shallow" To: , References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 19 Dec 2017 11:27:13 -0000 Message-ID: <03d401d378bc$51363c50$f3a2b4f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D5_01D378BC.5138AD50" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGht6CjVFygIRhvgE++pwgRVUADvAFJBRQ9AZNdS7ECuqXb9aOBTopQ Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:27:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03D5_01D378BC.5138AD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon1] =20 Regards =20 Jon =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:02 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats =20 Hi Jon,=20 =20 Thank you for initiating this thread. This is exactly the discussion I wanted to have.=20 =20 The initial requirement that motivated introducing config-interval was = the following from the requirements I-D: =20 When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. =20 Also, given that configuration changes may occur at the server, clients = will continue using stale configuration data retrieved previously from the = server because there is no procedure to refresh the config. This is = undesirable. config-interval solves this. Of course, DOTS agents may decide to = disable the refresh procedure by setting it to 0 or by not returning the = parameter. [Jon] I agree there may be stale signal configurations (most likely to = occur during initial set-up and tuning) and =93config-interval=94 will handle = this. The requirements I-D refer to this only being done when =91no mitigation request is active=92. The peacetime/attack (with possibly) alternative heartbeat configurations partially handle this requirement as well. [Med] Agree.=20 =20 =20 Having distinct heartbeat values (peacetime/attack) is an option, but it does not address the issue of stale configuration. Note that, for = example, a distinct max-retransmit may also be configured for peace time.=20 =20 The following would meet all the requirements: =20 =20 +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 [Jon] A minor comment =96 is the following more logical and more = descriptive? [Med] I considered this but favored the other one because it is more compact. For example, when the same config is to be used for both peace/attack times, you just need to omit =93peace-time-config=94, while = you need to include the same value twice for the other proposal. Do you have = a strong preference? [Jon1] Actually, I had sneaked in a ? after peace-time-config, making it optional (and all the elements below). As an implementer, I find my suggestion more readable / understandable =96 but am really agnostic as = to which definition version. =20 +--:(configuration) +--rw session-id int32 +--rw attack-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw peace-time-config? | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw config-interval? int32 =20 =B7 If no peace-time-config is provided, the same values will be = used for both peace and attack times till a change occurs. This is what is currently in the draft.=20 =B7 peace-time-config may be returned to specify values to be = used for peacetime. Switching between attack/peace time parameter values will be automatic. [Jon] We just need to make sure the =91automatic=92 switching is defined = in the text as well as updating CBOR mappings etc. =20 [Jon] How do we handle in the YANG definition the fact that, say, when = doing a GET, heartbeat-interval is =93heartbeat-interval=94:{=93current-value=94:xx,=94min-value=94:yy,=94ma= x-value=94:zz}, but a PUT currently is {=93heartbeat-interval=94:aa}. I think actually the = PUT should be {=93heartbeat-interval=94:{=93current-value=94:aa} and the = YANG definition updated accordingly. =20 [Med] A config parameter in the PUT implicitly means =93current = value=94. Is there a benefit in saying it explicitly? I don=92t think so. No? [Jon1] I agree that current-value is implicit, but if we are to strictly = use the YANG model, the GET returns information that is not YANG defined = (hence unparseable), so if the YANG definition is extended to include = current-value etc. then we need to update the PUT to be YANG compliant. =20 =20 =20 Your point (A) makes sense to me. What about adding the following: =20 NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. [Jon] Works for me [Med] Great! =20 I do fully agree that consistent setting of the parameters is important. = =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats =20 Hi there, =20 There has been a lot of discussion on this, culminating in an update in draft-ietf-dots-signal-channel-13 where =91config-interval=92 has been = added in to try to handle the different concerns. =20 >From my trying to simplify things perspective:- =20 1. NAT devices usually allow outbound session requests (source IP = nat=92ing) and allow for a response to come back within a defined time frame (lots = of discussion on this time frame =96 eventually setting on 30 seconds as a = good compromise =96 but could be longer). =20 2. NAT devices may be configured to allow inbound session requests (port redirection) and allow for a response to come back within a defined time frame. Doing this does raise security policy issues as this potentially allows uncontrolled access from the Internet to an internal device. =20 3. NAT devices are likely to break any server initiated heartbeats if = the server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security reasons). =20 4. The frequency of Heartbeats ideally are different between peace time = and attack. In peace time there could be no heartbeats or at a slow rate to keep the signal channel alive. In attack time, 30 seconds appears to be = the agreed compromise time, but this is also influenced by the underlying = COAP protocol (retry intervals and counters etc.). In attack time, the rate should be sufficient to detect any transmission issues within a = reasonable time frame. =20 5. For DOTS clients, there should be no issues with heartbeats going = through NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. =20 6. For DOTS servers dropping the heartbeat rate below that of the active = NAT session time will cause issues if there is a NAT device that does not = allow inbound initiated sessions. =20 7. If heartbeats are in use, then both DOTS server and DOTS client have = to do their separate heartbeats for network connectively / DOTS agent availability. =20 8. If heartbeats are being used, the DOTS server can optionally trigger mitigation is heartbeats stop working =20 To give the ability to change the heartbeat rates, =91config-interval=92 = has been added to the signal draft. A client then knows when to re-request = the configuration (e.g. for potentially changed heartbeat values). However, =91config-interval=92 has to be sufficiently large to not compete with = the heartbeat rate (if they both were for the same interval, then = configuration update requests would effectively be doing the same task as = heartbeats!). But if =91config-interval=92 is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get increased = in attack time (and if the config update response packet does not get = through, it will not get updated). I think =91config-interval=92 needs to be = thought through further. =20 I have 2 proposals here =20 A. If the heartbeat frequency is below that of the NAT session inactive timeout, the DOTS client will always transmit the heartbeats at the appropriate frequency. When the heartbeat request arrives at the DOTS server, this triggers a heartbeat process on the DOTS server to then heartbeat test the DOTS client. Thus the DOTS server can use the = =93warm=94 NAT session during peacetime. If the heartbeat requests do not come in from = the DOTS client (and a peacetime heartbeat rate is configured) then auto-mitigation can get invoked if required. =20 B. There are defined two heartbeat rates =96 one for when one or more mitigation requests are in progress (attack situations) and a second = rate for peace time (can be 0 (no heartbeats) or some long timeout). = Whenever the first mitigation is requested over a DOTS session, both ends start heart-beating at the =93attack=94 rate. This gets rid of any potential =91config-interval=92 refresh delays / =91new heartbeat interval=92 = packets getting lost. When there are no more mitigations active for that DOTS session, = then the DOTS session drops immediately back into the peacetime values. =91config-interval=92 could then be replaced with =91peace-time-heartbeat-interval=92. =20 Regards =20 Jon =20 =20 ------=_NextPart_000_03D5_01D378BC.5138AD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon1]

 

Regards

 

Jon

 

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 19 December 2017 10:02
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] Signal Channel Heartbeats

 

Hi Jon,

 

Thank you for initiating this thread. This is = exactly the discussion I wanted to have.

 

The initial requirement that motivated = introducing config-interval was the following from the requirements = I-D:

 

      = When DOTS agents are exchanging heartbeats and = no

      = mitigation request is active, either agent MAY request changes = to

      the = heartbeat rate.  For example, a DOTS server might want = to

      = reduce heartbeat frequency or cease heartbeat exchanges when = an

      = active DOTS client has not requested mitigation, in order = to

      = control = load.

 

Also, given that configuration changes may = occur at the server, clients will continue using stale configuration = data retrieved previously from the server because there is no procedure = to refresh the config. This is undesirable. config-interval solves this. = Of course, DOTS agents may decide to disable the refresh procedure by = setting it to 0 or by not returning the parameter.

[Jon] I = agree there may be stale signal configurations (most likely to occur = during initial set-up and tuning) and “config-interval” will = handle this. The requirements I-D refer to this only being done when = ‘no mitigation request is active’.  The = peacetime/attack (with possibly) alternative heartbeat configurations = partially handle this requirement as well.

[Med] Agree.

 

 

Having distinct heartbeat values = (peacetime/attack) is an option, but it does not address the issue of = stale configuration. Note that, for example, a distinct max-retransmit = may also be configured for peace time.

 

The following would meet all the requirements: =  

 

      =
;    =
+--:(configuration)
      =
;       +--rw =
session-id          &nb=
sp; int32
      =
;       +--rw =
heartbeat-interval?   int16
      =
;       +--rw =
missing-hb-allowed?   int16
      =
;       +--rw =
max-retransmit?       =
int16
      =
;       +--rw =
ack-timeout?          =
int16
      =
;       +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
trigger-mitigation?   =
Boolean
      =
;       +--rw =
peace-time-config
    =
         |   =
+--rw heartbeat-interval?   =
int16
    =
         |   =
+--rw missing-hb-allowed?   =
int16
      =
;       |   +--rw =
max-retransmit?       =
int16
      =
;       |   +--rw =
ack-timeout?          =
int16
      =
;       |   +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
config-interval?      =
int32

[Jon]  A minor comment – is the = following more logical and more descriptive?

[Med] I considered this but favored the other = one because it is more compact. For example, when the same config is to = be used for both peace/attack times, you just need to omit = “peace-time-config”, while you need to include the same = value twice for the other proposal. Do you have a strong = preference?

[Jon1] = Actually, I had sneaked in a ? after peace-time-config, making it = optional (and all the elements below).=A0 As an implementer, I find my = suggestion more readable / understandable – but am really agnostic = as to which definition version.

 

      =
;    =
+--:(configuration)
      =
;       +--rw =
session-id          &nb=
sp; int32
      =
;       +--rw =
attack-time-config
      =
;       |   +--rw =
heartbeat-interval?   int16
      =
;       |   +--rw =
missing-hb-allowed?   int16
      =
;       |   +--rw =
max-retransmit?       =
int16
      =
;       |   +--rw =
ack-timeout?          =
int16
      =
;       |   +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
peace-time-config?
    =
         |   =
+--rw heartbeat-interval?   =
int16
    =
         |   =
+--rw missing-hb-allowed?   =
int16
      =
;       |   +--rw =
max-retransmit?       =
int16
      =
;       |   +--rw =
ack-timeout?          =
int16
      =
;       |   +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
trigger-mitigation?   =
Boolean
      =
;       +--rw =
config-interval?      =
int32

 

=B7         = If no peace-time-config is provided, the same = values will be used for both peace and attack times till a change = occurs. This is what is currently in the draft.

=B7         = peace-time-config may be returned to specify = values to be used for peacetime. Switching between attack/peace time = parameter values will be automatic.

[Jon] We = just need to make sure the ‘automatic’ switching is defined = in the text as well as updating CBOR mappings = etc.

 

[Jon] How = do we handle in the YANG definition the fact that, say, when doing a = GET, heartbeat-interval is = “heartbeat-interval”:{“current-value”:xx,”m= in-value”:yy,”max-value”:zz}, but a PUT currently is = {“heartbeat-interval”:aa}.  I think actually the PUT = should be = {“heartbeat-interval”:{“current-value”:aa} and = the YANG definition updated accordingly.

 

[Med] A config parameter in the PUT implicitly = means “current value”. Is there a benefit in saying it = explicitly? I don’t think so. No?

[Jon1] I = agree that current-value is implicit, but if we are to strictly use the = YANG model, the GET returns information that is not YANG defined (hence = unparseable), so if the YANG definition is extended to include = current-value etc. then we need to update the PUT to be YANG = compliant.

   

 

 

Your point (A) makes sense to me. What about = adding the following:

 

NEW:

   In order to avoid =
complications due to the presence of some =
stateful
   translators and =
firewalls (e.g., discard an incoming packet =
because
   no matching state is =
found), DOTS servers MAY trigger their =
heartbeat
   requests immediately =
after receiving heartbeat probes from peer =
DOTS
   clients.
[Jon] = Works for me
[Med] =
Great!

 

I do fully agree that consistent setting of = the parameters is important.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 18 = d=E9cembre 2017 16:00
=C0 : dots@ietf.org
Objet : = [Dots] Signal Channel Heartbeats

 

Hi there,

 

There has = been a lot of discussion on this, culminating in an update in = draft-ietf-dots-signal-channel-13 where ‘config-interval’ = has been added in to try to handle the different = concerns.

 

From my trying to simplify things = perspective:-

 

1. NAT devices usually allow outbound session requests = (source IP nat’ing) and allow for a response to come back within a = defined time frame (lots of discussion on this time frame – = eventually setting on 30 seconds as a good compromise – but could = be longer).

 

2. NAT devices may be configured to allow inbound = session requests (port redirection) and allow for a response to come = back within a defined time frame.  Doing this does raise security = policy issues as this potentially allows uncontrolled access from the = Internet to an internal device.

 

3. NAT = devices are likely to break any server initiated heartbeats if the = server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security = reasons).

 

4. The frequency of Heartbeats ideally are different = between peace time and attack.  In peace time there could be no = heartbeats or at a slow rate to keep the signal channel alive.  In = attack time, 30 seconds appears to be the agreed compromise time, but = this is also influenced by the underlying COAP protocol  (retry = intervals and counters etc.).  In attack time, the rate should be = sufficient to detect any transmission issues within a reasonable time = frame.

 

5. For DOTS clients, there should be no issues with = heartbeats going through NAT devices (other than during an attack where = there may be packet loss) no matter what the heartbeat frequency = is.

 

6. For DOTS servers dropping the heartbeat rate below = that of the active NAT session time will cause issues if there is a NAT = device that does not allow inbound initiated sessions.

 

7. If = heartbeats are in use, then both DOTS server and DOTS client have to do = their separate heartbeats for network connectively / DOTS agent = availability.

 

8. If heartbeats are being used, the DOTS server can = optionally trigger mitigation is heartbeats stop = working

 

To give the ability to change the heartbeat rates, = ‘config-interval’ has been added to the signal draft.  = A client then knows when to re-request the configuration (e.g. for = potentially changed heartbeat values).  However, = ‘config-interval’ has to be sufficiently large to not = compete with the heartbeat rate (if they both were for the same = interval, then configuration update requests would effectively be doing = the same task as heartbeats!).  But if = ‘config-interval’ is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get = increased in attack time (and if the config update response packet does = not get through, it will not get updated).  I think = ‘config-interval’ needs to be thought through = further.

 

I have 2 proposals here

 

A. If the = heartbeat frequency is below that of the NAT session inactive timeout, = the DOTS client will always transmit the heartbeats at the appropriate = frequency.  When the heartbeat request arrives at the DOTS server, = this triggers a heartbeat process on the DOTS server to then heartbeat = test the DOTS client.  Thus the DOTS server can use the = “warm” NAT session during peacetime.  If the heartbeat = requests do not come in from the DOTS client (and a peacetime heartbeat = rate is configured) then auto-mitigation can get invoked if = required.

 

B. There are defined two heartbeat rates – one = for when one or more mitigation requests are in progress (attack = situations) and a second rate for peace time (can be 0 (no heartbeats) = or some long timeout).  Whenever the first mitigation is requested = over a DOTS session, both ends start heart-beating at the = “attack” rate.   This gets rid of any potential = ‘config-interval’ refresh delays / ‘new heartbeat = interval’ packets getting lost.  When there are no more = mitigations active for that DOTS session, then the DOTS session drops = immediately back into the peacetime values.  = ‘config-interval’ could then be replaced with = ‘peace-time-heartbeat-interval’.

 

Regards

 

Jon

 

 

------=_NextPart_000_03D5_01D378BC.5138AD50-- From nobody Tue Dec 19 03:31:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548F412DA51 for ; Tue, 19 Dec 2017 03:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeMJWC2CtrI6 for ; Tue, 19 Dec 2017 03:31:39 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8930112DA44 for ; Tue, 19 Dec 2017 03:31:38 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRG7U-00052b-O5; Tue, 19 Dec 2017 11:31:36 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 19 Dec 2017 11:31:37 -0000 Message-ID: <03e701d378bc$eecbba30$cc632e90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E8_01D378BC.EECE0420" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGht6CjVFygIRhvgE++pwgRVUADvAFJBRQ9AZNdS7ECuqXb9QIGRW4Io3EfA9A= Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:31:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E8_01D378BC.EECE0420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Proposal A just gives DOTS servers the capability to continue to do heartbeats through a NAT device, there is no NAT port redirection in = place on the NAT device and any outbound NAT session has an expiry timeout = that is smaller than the repeat frequency of the heartbeats. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 19 December 2017 11:26 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats =20 The CoAP messages for configuration update are marked as Confirmable, = and are not suitable to be exchanged during attack time. It does not sound = like a good idea to modify the DOTS signal channel configuration parameters during attack time. I don=92t see the need for proposal (A) discussion = below but agree with the proposed updated yang model with attack-time-config = and peace-time-config. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Tuesday, December 19, 2017 4:44 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 19 d=E9cembre 2017 11:49 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Signal Channel Heartbeats =20 Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:02 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats =20 Hi Jon,=20 =20 Thank you for initiating this thread. This is exactly the discussion I wanted to have.=20 =20 The initial requirement that motivated introducing config-interval was = the following from the requirements I-D: =20 When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. =20 Also, given that configuration changes may occur at the server, clients = will continue using stale configuration data retrieved previously from the = server because there is no procedure to refresh the config. This is = undesirable. config-interval solves this. Of course, DOTS agents may decide to = disable the refresh procedure by setting it to 0 or by not returning the = parameter. [Jon] I agree there may be stale signal configurations (most likely to = occur during initial set-up and tuning) and =93config-interval=94 will handle = this. The requirements I-D refer to this only being done when =91no mitigation request is active=92. The peacetime/attack (with possibly) alternative heartbeat configurations partially handle this requirement as well. [Med] Agree.=20 =20 =20 Having distinct heartbeat values (peacetime/attack) is an option, but it does not address the issue of stale configuration. Note that, for = example, a distinct max-retransmit may also be configured for peace time.=20 =20 The following would meet all the requirements: =20 =20 +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 [Jon] A minor comment =96 is the following more logical and more = descriptive? [Med] I considered this but favored the other one because it is more compact. For example, when the same config is to be used for both peace/attack times, you just need to omit =93peace-time-config=94, while = you need to include the same value twice for the other proposal. Do you have = a strong preference?=20 =20 +--:(configuration) +--rw session-id int32 +--rw attack-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw peace-time-config? | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw config-interval? int32 =20 =B7 If no peace-time-config is provided, the same values will be = used for both peace and attack times till a change occurs. This is what is currently in the draft.=20 =B7 peace-time-config may be returned to specify values to be = used for peacetime. Switching between attack/peace time parameter values will be automatic. [Jon] We just need to make sure the =91automatic=92 switching is defined = in the text as well as updating CBOR mappings etc. =20 [Jon] How do we handle in the YANG definition the fact that, say, when = doing a GET, heartbeat-interval is =93heartbeat-interval=94:{=93current-value=94:xx,=94min-value=94:yy,=94ma= x-value=94:zz}, but a PUT currently is {=93heartbeat-interval=94:aa}. I think actually the = PUT should be {=93heartbeat-interval=94:{=93current-value=94:aa} and the = YANG definition updated accordingly. =20 [Med] A config parameter in the PUT implicitly means =93current = value=94. Is there a benefit in saying it explicitly? I don=92t think so. No? =20 =20 =20 Your point (A) makes sense to me. What about adding the following: =20 NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. [Jon] Works for me [Med] Great! =20 I do fully agree that consistent setting of the parameters is important. = =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats =20 Hi there, =20 There has been a lot of discussion on this, culminating in an update in draft-ietf-dots-signal-channel-13 where =91config-interval=92 has been = added in to try to handle the different concerns. =20 >From my trying to simplify things perspective:- =20 1. NAT devices usually allow outbound session requests (source IP = nat=92ing) and allow for a response to come back within a defined time frame (lots = of discussion on this time frame =96 eventually setting on 30 seconds as a = good compromise =96 but could be longer). =20 2. NAT devices may be configured to allow inbound session requests (port redirection) and allow for a response to come back within a defined time frame. Doing this does raise security policy issues as this potentially allows uncontrolled access from the Internet to an internal device. =20 3. NAT devices are likely to break any server initiated heartbeats if = the server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security reasons). =20 4. The frequency of Heartbeats ideally are different between peace time = and attack. In peace time there could be no heartbeats or at a slow rate to keep the signal channel alive. In attack time, 30 seconds appears to be = the agreed compromise time, but this is also influenced by the underlying = COAP protocol (retry intervals and counters etc.). In attack time, the rate should be sufficient to detect any transmission issues within a = reasonable time frame. =20 5. For DOTS clients, there should be no issues with heartbeats going = through NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. =20 6. For DOTS servers dropping the heartbeat rate below that of the active = NAT session time will cause issues if there is a NAT device that does not = allow inbound initiated sessions. =20 7. If heartbeats are in use, then both DOTS server and DOTS client have = to do their separate heartbeats for network connectively / DOTS agent availability. =20 8. If heartbeats are being used, the DOTS server can optionally trigger mitigation is heartbeats stop working =20 To give the ability to change the heartbeat rates, =91config-interval=92 = has been added to the signal draft. A client then knows when to re-request = the configuration (e.g. for potentially changed heartbeat values). However, =91config-interval=92 has to be sufficiently large to not compete with = the heartbeat rate (if they both were for the same interval, then = configuration update requests would effectively be doing the same task as = heartbeats!). But if =91config-interval=92 is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get increased = in attack time (and if the config update response packet does not get = through, it will not get updated). I think =91config-interval=92 needs to be = thought through further. =20 I have 2 proposals here =20 A. If the heartbeat frequency is below that of the NAT session inactive timeout, the DOTS client will always transmit the heartbeats at the appropriate frequency. When the heartbeat request arrives at the DOTS server, this triggers a heartbeat process on the DOTS server to then heartbeat test the DOTS client. Thus the DOTS server can use the = =93warm=94 NAT session during peacetime. If the heartbeat requests do not come in from = the DOTS client (and a peacetime heartbeat rate is configured) then auto-mitigation can get invoked if required. =20 B. There are defined two heartbeat rates =96 one for when one or more mitigation requests are in progress (attack situations) and a second = rate for peace time (can be 0 (no heartbeats) or some long timeout). = Whenever the first mitigation is requested over a DOTS session, both ends start heart-beating at the =93attack=94 rate. This gets rid of any potential =91config-interval=92 refresh delays / =91new heartbeat interval=92 = packets getting lost. When there are no more mitigations active for that DOTS session, = then the DOTS session drops immediately back into the peacetime values. =91config-interval=92 could then be replaced with =91peace-time-heartbeat-interval=92. =20 Regards =20 Jon =20 =20 ------=_NextPart_000_03E8_01D378BC.EECE0420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Proposal A just gives = DOTS servers the capability to continue to do heartbeats through a NAT = device, there is no NAT port redirection in place on the NAT device and = any outbound NAT session has an expiry timeout that is smaller than the = repeat frequency of the heartbeats.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 19 December 2017 = 11:26
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] Signal Channel = Heartbeats

 

The CoAP messages for = configuration update are marked as Confirmable, and are not suitable to = be exchanged during attack time. It does not sound like a good idea to = modify the DOTS signal channel configuration parameters during attack = time. I don’t see the need for = proposal (A) discussion below but agree with the proposed updated yang = model with attack-time-config and = peace-time-config.

 

-Tiru

 

From: Dots = [mailto:dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: Tuesday, December 19, = 2017 4:44 PM
To: Jon Shallow = <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: = [Dots] Signal Channel Heartbeats

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mardi 19 d=E9cembre 2017 = 11:49
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] Signal Channel Heartbeats

 

Hi = Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 19 December 2017 10:02
To: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] Signal Channel Heartbeats

 

Hi Jon,

 

Thank you for initiating this thread. This is = exactly the discussion I wanted to have.

 

The initial requirement that motivated = introducing config-interval was the following from the requirements = I-D:

 

      = When DOTS agents are exchanging heartbeats and = no

      = mitigation request is active, either agent MAY request changes = to

      the = heartbeat rate.  For example, a DOTS server might want = to

      = reduce heartbeat frequency or cease heartbeat exchanges when = an

      = active DOTS client has not requested mitigation, in order = to

      = control = load.

 

Also, given that configuration changes may = occur at the server, clients will continue using stale configuration = data retrieved previously from the server because there is no procedure = to refresh the config. This is undesirable. config-interval solves this. = Of course, DOTS agents may decide to disable the refresh procedure by = setting it to 0 or by not returning the parameter.

[Jon] I = agree there may be stale signal configurations (most likely to occur = during initial set-up and tuning) and “config-interval” will = handle this. The requirements I-D refer to this only being done when = ‘no mitigation request is active’.  The = peacetime/attack (with possibly) alternative heartbeat configurations = partially handle this requirement as well.

[Med] Agree.

 

 

Having distinct heartbeat values = (peacetime/attack) is an option, but it does not address the issue of = stale configuration. Note that, for example, a distinct max-retransmit = may also be configured for peace time.

 

The following would meet all the requirements: =  

 

      =
;    =
+--:(configuration)
      =
;       +--rw =
session-id          &nb=
sp; int32
      =
;       +--rw =
heartbeat-interval?   int16
      =
;       +--rw =
missing-hb-allowed?   int16
      =
;       +--rw =
max-retransmit?       =
int16
      =
;       +--rw =
ack-timeout?          =
int16
      =
;       +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
trigger-mitigation?   =
Boolean
      =
;       +--rw =
peace-time-config
    =
         |   =
+--rw heartbeat-interval?   =
int16
    =
         |   =
+--rw missing-hb-allowed?   =
int16
      =
;       |   +--rw =
max-retransmit?       =
int16
      =
;       |   +--rw =
ack-timeout?          =
int16
      =
;       |   +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
config-interval?      =
int32

[Jon]  A minor comment – is the = following more logical and more descriptive?

[Med] I considered this but favored the other = one because it is more compact. For example, when the same config is to = be used for both peace/attack times, you just need to omit = “peace-time-config”, while you need to include the same = value twice for the other proposal. Do you have a strong preference? =

 

      =
;    =
+--:(configuration)
      =
;       +--rw =
session-id          &nb=
sp; int32
      =
;       +--rw =
attack-time-config
      =
;       |   +--rw =
heartbeat-interval?   int16
      =
;       |   +--rw =
missing-hb-allowed?   int16
      =
;       |   +--rw =
max-retransmit?       =
int16
      =
;       |   +--rw =
ack-timeout?          =
int16
      =
;       |   +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
peace-time-config?
    =
         |   =
+--rw heartbeat-interval?   =
int16
    =
         |   =
+--rw missing-hb-allowed?   =
int16
      =
;       |   +--rw =
max-retransmit?       =
int16
      =
;       |   +--rw =
ack-timeout?          =
int16
      =
;       |   +--rw =
ack-random-factor?    =
decimal64
      =
;       +--rw =
trigger-mitigation?   =
Boolean
      =
;       +--rw =
config-interval?      =
int32

 

=B7       &nb= sp; If no peace-time-config is provided, the same = values will be used for both peace and attack times till a change = occurs. This is what is currently in the draft.

=B7       &nb= sp; peace-time-config may be returned to specify = values to be used for peacetime. Switching between attack/peace time = parameter values will be automatic.

[Jon] We = just need to make sure the ‘automatic’ switching is defined = in the text as well as updating CBOR mappings = etc.

 

[Jon] How = do we handle in the YANG definition the fact that, say, when doing a = GET, heartbeat-interval is = “heartbeat-interval”:{“current-value”:xx,”m= in-value”:yy,”max-value”:zz}, but a PUT currently is = {“heartbeat-interval”:aa}.  I think actually the PUT = should be = {“heartbeat-interval”:{“current-value”:aa} and = the YANG definition updated accordingly.

 

[Med] A config parameter in the PUT implicitly = means “current value”. Is there a benefit in saying it = explicitly? I don’t think so. No? =    

 

 

Your point (A) makes sense to me. What about = adding the following:

 

NEW:

   In order to avoid =
complications due to the presence of some =
stateful
   translators and =
firewalls (e.g., discard an incoming packet =
because
   no matching state is =
found), DOTS servers MAY trigger their =
heartbeat
   requests immediately =
after receiving heartbeat probes from peer =
DOTS
   clients.
[Jon] = Works for me
[Med] =
Great!

 

I do fully agree that consistent setting of = the parameters is important.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 18 = d=E9cembre 2017 16:00
=C0 : dots@ietf.org
Objet : = [Dots] Signal Channel Heartbeats

 

Hi there,

 

There has = been a lot of discussion on this, culminating in an update in = draft-ietf-dots-signal-channel-13 where ‘config-interval’ = has been added in to try to handle the different = concerns.

 

From my trying to simplify things = perspective:-

 

1. NAT devices usually allow outbound session requests = (source IP nat’ing) and allow for a response to come back within a = defined time frame (lots of discussion on this time frame – = eventually setting on 30 seconds as a good compromise – but could = be longer).

 

2. NAT devices may be configured to allow inbound = session requests (port redirection) and allow for a response to come = back within a defined time frame.  Doing this does raise security = policy issues as this potentially allows uncontrolled access from the = Internet to an internal device.

 

3. NAT = devices are likely to break any server initiated heartbeats if the = server request frequency is longer than a NAT session is maintained in = the NAT device, and inbound session requests are disabled (for security = reasons).

 

4. The frequency of Heartbeats ideally are different = between peace time and attack.  In peace time there could be no = heartbeats or at a slow rate to keep the signal channel alive.  In = attack time, 30 seconds appears to be the agreed compromise time, but = this is also influenced by the underlying COAP protocol  (retry = intervals and counters etc.).  In attack time, the rate should be = sufficient to detect any transmission issues within a reasonable time = frame.

 

5. For DOTS clients, there should be no issues with = heartbeats going through NAT devices (other than during an attack where = there may be packet loss) no matter what the heartbeat frequency = is.

 

6. For DOTS servers dropping the heartbeat rate below = that of the active NAT session time will cause issues if there is a NAT = device that does not allow inbound initiated sessions.

 

7. If = heartbeats are in use, then both DOTS server and DOTS client have to do = their separate heartbeats for network connectively / DOTS agent = availability.

 

8. If heartbeats are being used, the DOTS server can = optionally trigger mitigation is heartbeats stop = working

 

To give the ability to change the heartbeat rates, = ‘config-interval’ has been added to the signal draft.  = A client then knows when to re-request the configuration (e.g. for = potentially changed heartbeat values).  However, = ‘config-interval’ has to be sufficiently large to not = compete with the heartbeat rate (if they both were for the same = interval, then configuration update requests would effectively be doing = the same task as heartbeats!).  But if = ‘config-interval’ is too large (signal draft-13 example has = it as 24 minutes) then it could take time for the heartbeat rate to get = increased in attack time (and if the config update response packet does = not get through, it will not get updated).  I think = ‘config-interval’ needs to be thought through = further.

 

I have 2 proposals here

 

A. If the = heartbeat frequency is below that of the NAT session inactive timeout, = the DOTS client will always transmit the heartbeats at the appropriate = frequency.  When the heartbeat request arrives at the DOTS server, = this triggers a heartbeat process on the DOTS server to then heartbeat = test the DOTS client.  Thus the DOTS server can use the = “warm” NAT session during peacetime.  If the heartbeat = requests do not come in from the DOTS client (and a peacetime heartbeat = rate is configured) then auto-mitigation can get invoked if = required.

 

B. There are defined two heartbeat rates – one = for when one or more mitigation requests are in progress (attack = situations) and a second rate for peace time (can be 0 (no heartbeats) = or some long timeout).  Whenever the first mitigation is requested = over a DOTS session, both ends start heart-beating at the = “attack” rate.   This gets rid of any potential = ‘config-interval’ refresh delays / ‘new heartbeat = interval’ packets getting lost.  When there are no more = mitigations active for that DOTS session, then the DOTS session drops = immediately back into the peacetime values.  = ‘config-interval’ could then be replaced with = ‘peace-time-heartbeat-interval’.

 

Regards

 

Jon

 

 

------=_NextPart_000_03E8_01D378BC.EECE0420-- From nobody Tue Dec 19 03:37:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272CC12DA51 for ; Tue, 19 Dec 2017 03:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xFxVu7rsl0L for ; Tue, 19 Dec 2017 03:37:52 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A5012D95E for ; Tue, 19 Dec 2017 03:37:51 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 58B8D4097F; Tue, 19 Dec 2017 12:37:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 31E541C007D; Tue, 19 Dec 2017 12:37:50 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 12:37:49 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel Heartbeats Thread-Index: AQGht6CjVFygIRhvgE++pwgRVUADvAFJBRQ9AZNdS7ECuqXb9aOBTopQgAAD9uA= Date: Tue, 19 Dec 2017 11:37:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09AB49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02c701d37810$d8eee0e0$8acca2a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AA66@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <03a301d378b7$0027e840$0077b8c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09AAF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <03d401d378bc$51363c50$f3a2b4f0$@jpshallow.com> In-Reply-To: <03d401d378bc$51363c50$f3a2b4f0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09AB49OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel Heartbeats X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:37:55 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09AB49OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, OK with having attack-time-config and peace-time-config. I understand better your comment "Jon1". Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 19 d=E9cembre 2017 12:27 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Signal Channel Heartbeats Hi Med, See inline [Jon1] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:02 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel Heartbeats Hi Jon, Thank you for initiating this thread. This is exactly the discussion I want= ed to have. The initial requirement that motivated introducing config-interval was the = following from the requirements I-D: When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Also, given that configuration changes may occur at the server, clients wil= l continue using stale configuration data retrieved previously from the ser= ver because there is no procedure to refresh the config. This is undesirabl= e. config-interval solves this. Of course, DOTS agents may decide to disabl= e the refresh procedure by setting it to 0 or by not returning the paramete= r. [Jon] I agree there may be stale signal configurations (most likely to occu= r during initial set-up and tuning) and "config-interval" will handle this.= The requirements I-D refer to this only being done when 'no mitigation req= uest is active'. The peacetime/attack (with possibly) alternative heartbea= t configurations partially handle this requirement as well. [Med] Agree. Having distinct heartbeat values (peacetime/attack) is an option, but it do= es not address the issue of stale configuration. Note that, for example, a = distinct max-retransmit may also be configured for peace time. The following would meet all the requirements: +--:(configuration) +--rw session-id int32 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw peace-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw config-interval? int32 [Jon] A minor comment - is the following more logical and more descriptive= ? [Med] I considered this but favored the other one because it is more compac= t. For example, when the same config is to be used for both peace/attack ti= mes, you just need to omit "peace-time-config", while you need to include t= he same value twice for the other proposal. Do you have a strong preference= ? [Jon1] Actually, I had sneaked in a ? after peace-time-config, making it op= tional (and all the elements below). As an implementer, I find my suggesti= on more readable / understandable - but am really agnostic as to which defi= nition version. +--:(configuration) +--rw session-id int32 +--rw attack-time-config | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw peace-time-config? | +--rw heartbeat-interval? int16 | +--rw missing-hb-allowed? int16 | +--rw max-retransmit? int16 | +--rw ack-timeout? int16 | +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean +--rw config-interval? int32 =B7 If no peace-time-config is provided, the same values will be us= ed for both peace and attack times till a change occurs. This is what is cu= rrently in the draft. =B7 peace-time-config may be returned to specify values to be used = for peacetime. Switching between attack/peace time parameter values will be= automatic. [Jon] We just need to make sure the 'automatic' switching is defined in the= text as well as updating CBOR mappings etc. [Jon] How do we handle in the YANG definition the fact that, say, when doin= g a GET, heartbeat-interval is "heartbeat-interval":{"current-value":xx,"mi= n-value":yy,"max-value":zz}, but a PUT currently is {"heartbeat-interval":a= a}. I think actually the PUT should be {"heartbeat-interval":{"current-val= ue":aa} and the YANG definition updated accordingly. [Med] A config parameter in the PUT implicitly means "current value". Is th= ere a benefit in saying it explicitly? I don't think so. No? [Jon1] I agree that current-value is implicit, but if we are to strictly us= e the YANG model, the GET returns information that is not YANG defined (hen= ce unparseable), so if the YANG definition is extended to include current-v= alue etc. then we need to update the PUT to be YANG compliant. Your point (A) makes sense to me. What about adding the following: NEW: In order to avoid complications due to the presence of some stateful translators and firewalls (e.g., discard an incoming packet because no matching state is found), DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. [Jon] Works for me [Med] Great! I do fully agree that consistent setting of the parameters is important. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 18 d=E9cembre 2017 16:00 =C0 : dots@ietf.org Objet : [Dots] Signal Channel Heartbeats Hi there, There has been a lot of discussion on this, culminating in an update in dra= ft-ietf-dots-signal-channel-13 where 'config-interval' has been added in to= try to handle the different concerns. >From my trying to simplify things perspective:- 1. NAT devices usually allow outbound session requests (source IP nat'ing) = and allow for a response to come back within a defined time frame (lots of = discussion on this time frame - eventually setting on 30 seconds as a good = compromise - but could be longer). 2. NAT devices may be configured to allow inbound session requests (port re= direction) and allow for a response to come back within a defined time fram= e. Doing this does raise security policy issues as this potentially allows= uncontrolled access from the Internet to an internal device. 3. NAT devices are likely to break any server initiated heartbeats if the s= erver request frequency is longer than a NAT session is maintained in the N= AT device, and inbound session requests are disabled (for security reasons)= . 4. The frequency of Heartbeats ideally are different between peace time and= attack. In peace time there could be no heartbeats or at a slow rate to k= eep the signal channel alive. In attack time, 30 seconds appears to be the= agreed compromise time, but this is also influenced by the underlying COAP= protocol (retry intervals and counters etc.). In attack time, the rate s= hould be sufficient to detect any transmission issues within a reasonable t= ime frame. 5. For DOTS clients, there should be no issues with heartbeats going throug= h NAT devices (other than during an attack where there may be packet loss) = no matter what the heartbeat frequency is. 6. For DOTS servers dropping the heartbeat rate below that of the active NA= T session time will cause issues if there is a NAT device that does not all= ow inbound initiated sessions. 7. If heartbeats are in use, then both DOTS server and DOTS client have to = do their separate heartbeats for network connectively / DOTS agent availabi= lity. 8. If heartbeats are being used, the DOTS server can optionally trigger mit= igation is heartbeats stop working To give the ability to change the heartbeat rates, 'config-interval' has be= en added to the signal draft. A client then knows when to re-request the c= onfiguration (e.g. for potentially changed heartbeat values). However, 'co= nfig-interval' has to be sufficiently large to not compete with the heartbe= at rate (if they both were for the same interval, then configuration update= requests would effectively be doing the same task as heartbeats!). But if= 'config-interval' is too large (signal draft-13 example has it as 24 minut= es) then it could take time for the heartbeat rate to get increased in atta= ck time (and if the config update response packet does not get through, it = will not get updated). I think 'config-interval' needs to be thought throu= gh further. I have 2 proposals here A. If the heartbeat frequency is below that of the NAT session inactive tim= eout, the DOTS client will always transmit the heartbeats at the appropriat= e frequency. When the heartbeat request arrives at the DOTS server, this t= riggers a heartbeat process on the DOTS server to then heartbeat test the D= OTS client. Thus the DOTS server can use the "warm" NAT session during pea= cetime. If the heartbeat requests do not come in from the DOTS client (and= a peacetime heartbeat rate is configured) then auto-mitigation can get inv= oked if required. B. There are defined two heartbeat rates - one for when one or more mitigat= ion requests are in progress (attack situations) and a second rate for peac= e time (can be 0 (no heartbeats) or some long timeout). Whenever the first= mitigation is requested over a DOTS session, both ends start heart-beating= at the "attack" rate. This gets rid of any potential 'config-interval' r= efresh delays / 'new heartbeat interval' packets getting lost. When there = are no more mitigations active for that DOTS session, then the DOTS session= drops immediately back into the peacetime values. 'config-interval' could= then be replaced with 'peace-time-heartbeat-interval'. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A09AB49OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

OK with having attack-time-config and peace-time-c= onfig.

 

I understand better= your comment “Jon1”.

 

Cheers,<= /span>

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 19 d=E9cembre 2017 12:27
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Signal Channel Heartbeats<= /p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon1]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 19 December 2017 10:02
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal Channel Heartbeats

 

Hi Jon,

 

Thank you for initiating this t= hread. This is exactly the discussion I wanted to have.

 

The initial requirement that mo= tivated introducing config-interval was the following from the requirements= I-D:

 

   &= nbsp;  When DOTS agents are exchanging heartbeats and no

   &= nbsp;  mitigation request is active, either agent MAY request changes = to

   &= nbsp;  the heartbeat rate.  For example, a DOTS server might want= to

   &= nbsp;  reduce heartbeat frequency or cease heartbeat exchanges when an=

   &= nbsp;  active DOTS client has not requested mitigation, in order to

   &= nbsp;  control load.

 

Also, given that configuration = changes may occur at the server, clients will continue using stale configur= ation data retrieved previously from the server because there is no procedure to refresh the config. This is undesirable. = config-interval solves this. Of course, DOTS agents may decide to disable t= he refresh procedure by setting it to 0 or by not returning the parameter.<= /span>

[Jon] I= agree there may be stale signal configurations (most likely to occur durin= g initial set-up and tuning) and “config-interval” will handle = this. The requirements I-D refer to this only being done when ‘no mitigation request is active’.  The peaceti= me/attack (with possibly) alternative heartbeat configurations partially ha= ndle this requirement as well.

[Med] Agree.

 

 

Having distinct heartbeat value= s (peacetime/attack) is an option, but it does not address the issue of sta= le configuration. Note that, for example, a distinct max-retransmit may also be configured for peace time.

 

The following would meet all th= e requirements:  

 

      &=
nbsp;   +--:(configuration)
      &=
nbsp;      +--rw session-id   &=
nbsp;        int32

      &=
nbsp;      +--rw heartbeat-interval? &nbs=
p; int16


      &=
nbsp;      +--rw missing-hb-allowed? &nbs=
p; int16


      &=
nbsp;      +--rw max-retransmit?  &n=
bsp;    int16


      &=
nbsp;      +--rw ack-timeout?   =
;       int16


      &=
nbsp;      +--rw ack-random-factor?  =
;  decimal64


      &=
nbsp;      +--rw trigger-mitigation? &nbs=
p; Boolean


      &=
nbsp;      +--rw peace-time-config<=
/span>


       =
      |   +--rw heartbeat-inter=
val?   int16


       =
      |   +--rw missing-hb-allo=
wed?   int16


      &=
nbsp;      |   +--rw max-retransmit?=
       int16


      &=
nbsp;      |   +--rw ack-timeout?&nb=
sp;         int16=



      &=
nbsp;      |   +--rw ack-random-fact=
or?    decimal64


      &=
nbsp;      +--rw config-interval?  &=
nbsp;   int32


[Jon]&n=
bsp; A minor comment – is the following more logical and more descrip=
tive?


[Med] I considered this but fav=
ored the other one because it is more compact. For example, when the same c=
onfig is to be used for both peace/attack times,
 you just need to omit “peace=
-time-config”, while you need to include
 the same value twice for the other proposal. Do you have a strong preferen=
ce?


[Jon1] =
Actually, I had sneaked in a ? after peace-time-config, making it optional =
(and all the elements below).  As an implementer, I find my suggestion=
 more readable / understandable – but am really
 agnostic as to which definition version.


 


 


      &=
nbsp;   +--:(configuration)


      &=
nbsp;      +--rw session-id   &=
nbsp;        int32

      &=
nbsp;      +--rw attack-time-config=



      &=
nbsp;      |   +--rw heartbeat-inter=
val?   int16


      &=
nbsp;      |   +--rw missing-hb-allo=
wed?   int16


      &=
nbsp;      |   +--rw max-retransmit?=
       int16


      &=
nbsp;      |   +--rw ack-timeout?&nb=
sp;         int16=



      &=
nbsp;      |   +--rw ack-random-fact=
or?    decimal64


      &=
nbsp;      +--rw peace-time-config?=



       =
      |   +--rw heartbeat-inter=
val?   int16


       =
      |   +--rw missing-hb-allo=
wed?   int16


      &=
nbsp;      |   +--rw max-retransmit?=
       int16


      &=
nbsp;      |   +--rw ack-timeout?&nb=
sp;         int16=



      &=
nbsp;      |   +--rw ack-random-fact=
or?    decimal64


      &=
nbsp;      +--rw trigger-mitigation? &nbs=
p; Boolean


      &=
nbsp;      +--rw config-interval?  &=
nbsp;   int32


&n=
bsp;


=B7    &n=
bsp;   
If no peace-time-config=
 is provided, the same values will be used for both peace and attack times =
till a change occurs. This is what is currently
 in the draft. 


=B7    &n=
bsp;   
peace-time-config may b=
e returned to specify values to be used for peacetime. Switching between at=
tack/peace time parameter values will be automatic.


[Jon] W=
e just need to make sure the ‘automatic’ switching is defined i=
n the text as well as updating CBOR mappings etc.


&n=
bsp;


[Jon] H=
ow do we handle in the YANG definition the fact that, say, when doing a GET=
, heartbeat-interval is “heartbeat-interval”:{“current-va=
lue”:xx,”min-value”:yy,”max-value”:zz}, but a=
 PUT currently
 is {“heartbeat-interval”:aa}.  I think actually the PUT s=
hould be {“heartbeat-interval”:{“current-value”:aa}=
 and the YANG definition updated accordingly.


 


[Med] A config parameter in the=
 PUT implicitly means “current value”. Is there a benefit in sa=
ying it explicitly? I don’t think so. No?[Jon1] =
I agree that current-value is implicit, but if we are to strictly use the Y=
ANG model, the GET returns information that is not YANG defined (hence unpa=
rseable), so if the YANG definition is
 extended to include current-value etc. then we need to update the PUT to b=
e YANG compliant.


   


 


 


Your point (A) makes sense to m=
e. What about adding the following:


 


NEW:


   In order to avoid compli=
cations due to the presence of some stateful


   translators and firewall=
s (e.g., discard an incoming packet because


   no matching state is fou=
nd), DOTS servers MAY trigger their heartbeat


   requests immediately aft=
er receiving heartbeat probes from peer DOTS


   clients.


[Jon] Works for =
me


[Med] Great!


 


I do fully agree that consisten=
t setting of the parameters is important.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Jon Shallow

Envoy=E9 : lundi 18 d=E9cembre 2017 16:00

=C0 : dots@ietf.org

Objet : [Dots] Signal Channel Heartbeats






 


Hi there,


 


There has been a lot of discuss=
ion on this, culminating in an update in draft-ietf-dots-signal-channel-13 =
where ‘config-interval’ has been added in to try to handle the =
different concerns.


 


From my trying to simplify thin=
gs perspective:-


 


1. NAT devices usually allow ou=
tbound session requests (source IP nat’ing) and allow for a response =
to come back within a defined time frame (lots of discussion on this time f=
rame – eventually setting on 30 seconds as
 a good compromise – but could be longer).


 


2. NAT devices may be configure=
d to allow inbound session requests (port redirection) and allow for a resp=
onse to come back within a defined time frame.  Doing this does raise =
security policy issues as this potentially
 allows uncontrolled access from the Internet to an internal device.


 


3. NAT devices are likely to br=
eak any server initiated heartbeats if the server request frequency is long=
er than a NAT session is maintained in the NAT device, and inbound session =
requests are disabled (for security
 reasons).


 


4. The frequency of Heartbeats =
ideally are different between peace time and attack.  In peace time th=
ere could be no heartbeats or at a slow rate to keep the signal channel ali=
ve.  In attack time, 30 seconds appears to
 be the agreed compromise time, but this is also influenced by the underlyi=
ng COAP protocol  (retry intervals and counters etc.).  In attack=
 time, the rate should be sufficient to detect any transmission issues with=
in a reasonable time frame.


 


5. For DOTS clients, there shou=
ld be no issues with heartbeats going through NAT devices (other than durin=
g an attack where there may be packet loss) no matter what the heartbeat fr=
equency is.


 


6. For DOTS servers dropping th=
e heartbeat rate below that of the active NAT session time will cause issue=
s if there is a NAT device that does not allow inbound initiated sessions.<=
o:p>


 


7. If heartbeats are in use, th=
en both DOTS server and DOTS client have to do their separate heartbeats fo=
r network connectively / DOTS agent availability.


 


8. If heartbeats are being used=
, the DOTS server can optionally trigger mitigation is heartbeats stop work=
ing


 


To give the ability to change t=
he heartbeat rates, ‘config-interval’ has been added to the sig=
nal draft.  A client then knows when to re-request the configuration (=
e.g. for potentially changed heartbeat values).  However,
 ‘config-interval’ has to be sufficiently large to not compete =
with the heartbeat rate (if they both were for the same interval, then conf=
iguration update requests would effectively be doing the same task as heart=
beats!).  But if ‘config-interval’ is too large
 (signal draft-13 example has it as 24 minutes) then it could take time for=
 the heartbeat rate to get increased in attack time (and if the config upda=
te response packet does not get through, it will not get updated).  I =
think ‘config-interval’ needs to be thought
 through further.


 


I have 2 proposals here


 


A. If the heartbeat frequency i=
s below that of the NAT session inactive timeout, the DOTS client will alwa=
ys transmit the heartbeats at the appropriate frequency.  When the hea=
rtbeat request arrives at the DOTS server,
 this triggers a heartbeat process on the DOTS server to then heartbeat tes=
t the DOTS client.  Thus the DOTS server can use the “warm”=
; NAT session during peacetime.  If the heartbeat requests do not come=
 in from the DOTS client (and a peacetime heartbeat rate
 is configured) then auto-mitigation can get invoked if required.


 


B. There are defined two heartb=
eat rates – one for when one or more mitigation requests are in progr=
ess (attack situations) and a second rate for peace time (can be 0 (no hear=
tbeats) or some long timeout).  Whenever the
 first mitigation is requested over a DOTS session, both ends start heart-b=
eating at the “attack” rate.   This gets rid of any p=
otential ‘config-interval’ refresh delays / ‘new heartbea=
t interval’ packets getting lost.  When there are no more mitiga=
tions active
 for that DOTS session, then the DOTS session drops immediately back into t=
he peacetime values.  ‘config-interval’ could then be repl=
aced with ‘peace-time-heartbeat-interval’.

 


Regards


 


Jon


 


 
--_000_787AE7BB302AE849A7480A190F8B93300A09AB49OPEXCLILMA3corp_-- From nobody Tue Dec 19 03:53:33 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6EB126BFD for ; Tue, 19 Dec 2017 03:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1mpCFKJ1OgX for ; Tue, 19 Dec 2017 03:53:29 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BE412025C for ; Tue, 19 Dec 2017 03:53:29 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRGSb-00053n-SL; Tue, 19 Dec 2017 11:53:25 +0000 From: "Jon Shallow" To: "'kaname nishizuka'" , , , References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> <787AE7BB302AE849A7480A190F8B93300A0950AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4783df7e-3a98-2c8d-1c92-e85f73e292bd@nttv6.jp> In-Reply-To: <4783df7e-3a98-2c8d-1c92-e85f73e292bd@nttv6.jp> Date: Tue, 19 Dec 2017 11:53:26 -0000 Message-ID: <041401d378bf$fb176f20$f1464d60$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGqp9s7Rd+tZsYBc/NKbOxjivvnjAETZNHTAS9HInqjiH0FoA== Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 11:53:31 -0000 Hi Roman et all, I have the following comments on the Requirements Document. 1.1 Context and Motivation "Once-staggering attack traffic volume is now the norm," makes no sense = to me - especially "Once-staggering". I suggest "High volume (leading = to inbound pipe saturating) attacks now frequently occur," 2. Requirements I concur with Med's comments (as per his pdf updates). This section = really refers to the signal channel, with a bit of the data channel = thrown in (e.g. white/black lists) right at the end. SIG-003 Original: In such circumstances, DOTS clients MAY attempt to reestablish the signal channel. Replacement. In such circumstances, DOTS clients MAY attempt to re-establish the = signal channel, but SHOULD continue to send heartbeats so that the DOTS = server knows the session is still partially alive. [see dots signal draft Section 4.7, first bullet point] SIG-007 IPv4 addresses in dotted quad format IPv6 addresses [RFC4291][RFC5952] Are no longer valid now that target-ip has been dropped in the signal / = data channels. I agree with Med's comments in his PDF update SEC-005 - Added in Med's PDF comments. I disagree with the MUST NOT as in "DOTS Gateways: Client-side DOTS = gateways MUST NOT reveal the identity of internal DOTS clients to a DOTS = server." If a Client Managed Domain Gateway has clients that are all public IP = addresses, then the Client Domain owner could elect to let the (hashed = to obfuscate) client-identifiers through so that the DOTS server can = differentiate between the individual clients when matching = mitigation-ids, alias-names etc. I believe that this text should be = something similar to "DOTS Gateways: Client Managed Domain DOTS gateways MUST NOT reveal the = identity of internal DOTS clients to a DOTS server if they are not = public IP addresses, and SHOULD NOT reveal the internal DOTS clients = identity to a DOTS server in a different managed domain." Otherwise, in general, I support to go to WGLC. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 15 December 2017 05:19 To: mohamed.boucadair@orange.com; Roman Danyliw; dots@ietf.org Subject: Re: [Dots] WGLC on DOTS Requirements Hi, I support the document to go WGLC process. I also support the comment from Med which is adding SEC-005. It reflects = the latest discussion about the client identifier. > - Add some text about the expected behavior of client-side DOTS = gateways to prevent leaking privacy information + server-side DOTS = gateways to help servers to enforce policies. thank you, Kaname On 2017/12/08 18:40, mohamed.boucadair@orange.com wrote: > Hi all, > > I support this document to be advanced in the publication process. > > I have the following comments: > - Align the text with the outcome of recent discussions: for example, = supplying a lifetime is a MUST. > - Add some text about the expected behavior of client-side DOTS = gateways to prevent leaking privacy information + server-side DOTS = gateways to help servers to enforce policies. > - Add some text about resolution libraries at DOTS servers to handle = requests having FQDN/URIs as mitigation scope. > - Update DM versioning requirement; no need to mention the text about = version 1. > > The detailed comments and other easy-to-fix nits are available at:=20 > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-iet > f-dots-requirements-08-rev%20Med.pdf > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw=20 >> Envoy=C3=A9 : jeudi 7 d=C3=A9cembre 2017 21:51 =C3=80 : dots@ietf.org = Objet : [Dots]=20 >> WGLC on DOTS Requirements >> >> Hello! >> >> Consistent with our discussion at the Singapore meeting and with the=20 >> concurrence of the draft authors, we are starting a working group=20 >> last call (WGLC) for the DOTS Requirements draft: >> >> Distributed Denial of Service (DDoS) Open Threat Signaling=20 >> Requirements >> draft-ietf-dots-requirements-08 >> https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >> >> Please send all comments to the DOTS mailing list. >> >> This WGLC will end on January 2, 2018 (~3 weeks to account for=20 >> end-of-the- calendar year vacations). >> >> Thanks, >> Roman >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 04:01:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8F12DA6A for ; Tue, 19 Dec 2017 04:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9XEVbaTXlNw for ; Tue, 19 Dec 2017 04:01:34 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B8712025C for ; Tue, 19 Dec 2017 04:01:33 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRGaS-00054i-Ff; Tue, 19 Dec 2017 12:01:32 +0000 From: "Jon Shallow" To: , , References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> <787AE7BB302AE849A7480A190F8B93300A09AA83@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09AA83@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 19 Dec 2017 12:01:33 -0000 Message-ID: <041901d378c1$1d219e00$5764da00$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGqp9s7Rd+tZsYBc/NKbOxjivvnjAGsNuuso47OtaA= Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 12:01:35 -0000 Hi Roman and others, What triggered these term change requests was the difference in interpretation of the word "side". 'Ahh =96 the light bulb has gone off =96 why our discussions had a = disconnect. It is down to the interpretation of the word =93side=94 as used in = =93Client Side DOTS gateway=94. To you (i.e. Med) it meant =93control or ownership=94, = to me (i.e. Jon) =93connectivity or position relative to DOTS gateway=94' It actually is recorded in https://www.ietf.org/mail-archive/web/dots/current/msg01767.html=20 Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:16 To: Roman Danyliw; dots@ietf.org Subject: Re: [Dots] WGLC on DOTS Requirements Re-, I'm extracting this comment from Jon to be handled as part of the WGLC comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jon said:=20 To prevent others getting confused, my suggestion would be to update the following in the various draft specs "Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway" "Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway" "DOTS gateway server-side" to "DOTS gateway server-facing-side" "DOTS gateway client-side" to "DOTS gateway client-facing-side" The latter 2 should be defined somewhere. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please refer to: https://www.ietf.org/mail-archive/web/dots/current/msg01765.html. I like the initial wording, but it seems this is not clear enough and = may lead to confusion.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw = > Envoy=E9=A0: jeudi 7 d=E9cembre 2017 21:51 =C0=A0: dots@ietf.org = Objet=A0: [Dots]=20 > WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the Singapore meeting and with the=20 > concurrence of the draft authors, we are starting a working group last = > call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling=20 > Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >=20 > Please send all comments to the DOTS mailing list. >=20 > This WGLC will end on January 2, 2018 (~3 weeks to account for=20 > end-of-the- calendar year vacations). >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 07:19:29 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E03129516; Tue, 19 Dec 2017 07:19:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151369676873.7503.16975686179952810632@ietfa.amsl.com> Date: Tue, 19 Dec 2017 07:19:28 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 15:19:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-14.txt Pages : 84 Date : 2017-12-19 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX o This RFC Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-14 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 19 07:34:15 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88432126DCA; Tue, 19 Dec 2017 07:34:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151369764852.7494.6746066350941906887@ietfa.amsl.com> Date: Tue, 19 Dec 2017 07:34:08 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-09.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 15:34:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-09.txt Pages : 20 Date : 2017-12-19 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-09 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 19 07:34:41 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3FE129C6D for ; Tue, 19 Dec 2017 07:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tYBymGAvhy7 for ; Tue, 19 Dec 2017 07:34:39 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E0E12D7E5 for ; Tue, 19 Dec 2017 07:34:39 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 8F61B120CFE for ; Tue, 19 Dec 2017 16:34:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 73745180089 for ; Tue, 19 Dec 2017 16:34:37 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 16:34:37 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzGGmVE1gcrXEO34qdqwVtSAqNKyOAw Date: Tue, 19 Dec 2017 15:34:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> In-Reply-To: <151369676873.7503.16975686179952810632@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 15:34:41 -0000 Re-, This version integrates the outcomes of the mailing list discussion, in par= ticular: - Multiple client-id values does not mean anymore that multiple GWs have in= jected a value each.=20 - Introduce attack-time-config and peace-time-config - Add some text to suggest dots servers to send heartbeats immediately afte= r receiving the one from the peer dots client.=20 - Refreshing the configuration must not occur during attack times.=20 The document is still using client-side and server-side DOTS GW terms. The = text will be aligned with the requirements I-D. Jon, please double check.=20 All, please review and share your comments. Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-14.txt > Pages : 84 > Date : 2017-12-19 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 07:55:44 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A047124BFA for ; Tue, 19 Dec 2017 07:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7I3Emb3i4fJ for ; Tue, 19 Dec 2017 07:55:41 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6D11241F3 for ; Tue, 19 Dec 2017 07:55:40 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513698935; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=C fqxBtlF+rtGGezUNxIjRIHN5HqpWK26DVWlYgL3As M=; b=nmv53nyCmFght+gDa+4oM3s8JKpT7SRjIjRKQGPZ9qwr wTa/XhC8HOm64QxAqM9rXV7ofhY0xN13MP8XfNFmetrBeQT4id 42ik+BRXm85eZete0P6p4aKprGbWtKgMJtx54ZD6GJE/liB8Ok FvRJHVeS6dzaQGXkZ1F+Kg4i4a4= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 73e9_2eb9_d5f3fdeb_172e_4013_99bf_52e98e373a40; Tue, 19 Dec 2017 09:55:34 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 08:55:02 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 19 Dec 2017 08:55:02 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 08:55:01 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 15:55:00 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 15:55:00 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTA= Date: Tue, 19 Dec 2017 15:55:00 +0000 Message-ID: References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:uBFCuGt6NF1Z1jpbZ8+mDjPcwbj7qjdctER6H8Yy3FmtsVGLurX0ydX06sa/agCf/IM6YwCTH9uzQnDXGhvauJ9PY67cb0E074jfOHSKbtUpEVqQVxmFKCCZD/cTdytU/aeT2V9lnwIKU2Cu4hxyhnUDSatD1Lc1VE23C1TMTtLgMbxTOt2+TCdzWr4qBTOVu0tNr7uSHOnWYYfmqHn3kB2vvW4wZ6lOeLQYKYR8Oe7lKVMAw4aJK1Sn+VgAH5XG1RfxYLstnSf+CyU6czFfBYwTrK4DDoRKlcqUAeENmZ3e2UYJiN7oc/zOkD0MyYlsBVeMRTIRPxn8RR1fWn6kLYyVcfBVwT2qnXn9Fg9BCCo=; 5:a5asN1QU6YVZn1SEw1zERqWfS5wRrRFRpLMXef4cYVQIgdt9fiYfZZouVUzSiBvDPvMdjnJn3FazmpKjLjTEB0oXIbdDLDA6FOHT6TcdVoUXAsyQzvVDhua+gUiMIcqUHelvCTaHZEbknU5G6dIYKrnGlezcSMuCJg+Mjn9YUi0=; 24:5CHiLKfNQjZxng+s3rEhQiyD4Pin4oSGaQdv1zBuc5h7xSaCxg22ac92eKlvhLYJf66+AbWpoJ24LlC7t2Uc/snDTb3tTwJSGV/m+0M8d7E=; 7:3sCsGd9+5pU8TwfaFhuLeKlkjLQOhLKs9nY9ZS/RnaOSLxGTA5Wsu1GeYHo48xoyKoWbEoTc+xYL/qtDbcsVB3PWvhYiPmr9jQz1ccZL7gKwiHU0xTUgKrXs86g2I3kXK5gE3pT5UG3j8O+JPtFMf+OK0eU80iw200aqS9eBUKtcScmf5MUhVtVkbq/5xFyofiDA1hsKsu5/MQuutIun97tZWBc38t8KbHwl5rAeCGQKM6EBQZYlZ9PgM9beRaOg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 06df4cd8-083b-4cf1-67d3-08d546f8dc71 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(396003)(32952001)(55784002)(189003)(377424004)(13464003)(199004)(6306002)(5660300001)(81166006)(53936002)(81156014)(4001150100001)(6246003)(8676002)(8936002)(7736002)(68736007)(6436002)(2501003)(2900100001)(33656002)(230783001)(3660700001)(3280700002)(53546011)(6506007)(72206003)(478600001)(77096006)(9686003)(966005)(80792005)(74316002)(305945005)(55016002)(97736004)(14454004)(105586002)(110136005)(106356001)(2950100002)(86362001)(7696005)(59450400001)(76176011)(99286004)(229853002)(6116002)(102836003)(316002)(3846002)(2906002)(66066001)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06df4cd8-083b-4cf1-67d3-08d546f8dc71 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 15:55:00.4702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6183> : inlines <6264> : streams <1773579> : uri <2553875> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 15:55:42 -0000 I don't think the DOTS signal channel draft should enhance the functionalit= y of DOTS gateway to aggregate mitigation requests, it's not discussed in a= ny of the requirements and architecture drafts. Why should the DOTS server send heartbeat request immediately after receivi= ng the heartbeat request from the client, DOTS server anyways will send a h= eartbeat response (CoAP Reset message) for the heartbeat request from the c= lient and that will keep the NAT binding alive.=20 Why cannot the client-identifier be generated by client-side DOTS gateway (= I don't understand the privacy problem, if the client-identifier does not r= eveal the actual DOTS client identity) ? -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Tuesday, December 19, 2017 9:05 PM > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Re-, >=20 > This version integrates the outcomes of the mailing list discussion, in > particular: > - Multiple client-id values does not mean anymore that multiple GWs have > injected a value each. > - Introduce attack-time-config and peace-time-config > - Add some text to suggest dots servers to send heartbeats immediately > after receiving the one from the peer dots client. > - Refreshing the configuration must not occur during attack times. >=20 > The document is still using client-side and server-side DOTS GW terms. Th= e > text will be aligned with the requirements I-D. >=20 > Jon, please double check. >=20 > All, please review and share your comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0: > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Action: > > draft-ietf-dots-signal-channel-14.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the > > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-14.txt > > Pages : 84 > > Date : 2017-12-19 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > o This RFC > > > > Please update TBD statements with the port number to be assigned to > > DOTS Signal Channel Protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > > 4 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 08:13:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC39F12D7E3 for ; Tue, 19 Dec 2017 08:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzIXlPXcqET5 for ; Tue, 19 Dec 2017 08:13:55 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8239129C6E for ; Tue, 19 Dec 2017 08:13:54 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 1F555A05AA; Tue, 19 Dec 2017 17:13:53 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 03D6E2006A; Tue, 19 Dec 2017 17:13:53 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 17:13:52 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMA== Date: Tue, 19 Dec 2017 16:13:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 16:13:57 -0000 Hi Tiru,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > I don't think the DOTS signal channel draft should enhance the > functionality of DOTS gateway to aggregate mitigation requests, it's not > discussed in any of the requirements and architecture drafts. [Med] IMO, it is out of the scope of the document to recommend or preclude = this. The main outcome of the discussion is that we don't have anymore a co= nfusion to interpret the presence of multiple client-ids. The only provisio= n is when a gateway decides to aggregate. Why and how aggregation is done i= s really out of scope.=20 > Why should the DOTS server send heartbeat request immediately after > receiving the heartbeat request from the client, DOTS server anyways will > send a heartbeat response (CoAP Reset message) for the heartbeat request > from the client and that will keep the NAT binding alive. [Med] The problem is not in that direction. The problem is when the server = sends a heartbeat request to the client but no mapping is found in the tran= slator/firewall. Sending immediately the probe while the NAT mapping is lik= ely to be open will ease nat traversal. This is a MAY. A serever is not obl= iged to follow it.=20 > Why cannot the client-identifier be generated by client-side DOTS gateway > (I don't understand the privacy problem, if the client-identifier does no= t > reveal the actual DOTS client identity) ? [Med] because, e.g., "DOTS server can fully trust the server-side gateway b= ut cannot fully trust the client-side gateway".=20 A network operator can decide to deploy multiple DOTS clients and hide the = identity of these clients. To that purpose, it can enable GW in its domain = to hide those clients.=20 >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Tuesday, December 19, 2017 9:05 PM > > To: dots@ietf.org > > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > Re-, > > > > This version integrates the outcomes of the mailing list discussion, in > > particular: > > - Multiple client-id values does not mean anymore that multiple GWs hav= e > > injected a value each. > > - Introduce attack-time-config and peace-time-config > > - Add some text to suggest dots servers to send heartbeats immediately > > after receiving the one from the peer dots client. > > - Refreshing the configuration must not occur during attack times. > > > > The document is still using client-side and server-side DOTS GW terms. > The > > text will be aligned with the requirements I-D. > > > > Jon, please double check. > > > > All, please review and share your comments. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0: > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Actio= n: > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the DDoS Open Threat Signaling WG of the > > > IETF. > > > > > > Title : Distributed Denial-of-Service Open Threat > > > Signaling (DOTS) Signal Channel > > > Authors : Tirumaleswar Reddy > > > Mohamed Boucadair > > > Prashanth Patil > > > Andrew Mortensen > > > Nik Teague > > > Filename : draft-ietf-dots-signal-channel-14.txt > > > Pages : 84 > > > Date : 2017-12-19 > > > > > > Abstract: > > > This document specifies the DOTS signal channel, a protocol for > > > signaling the need for protection against Distributed Denial-of- > > > Service (DDoS) attacks to a server capable of enabling network > > > traffic mitigation on behalf of the requesting client. > > > > > > A companion document defines the DOTS data channel, a separate > > > reliable communication layer for DOTS management and configuration > > > purposes. > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > Please update these statements with the RFC number to be assigned > to > > > this document: > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > > (DOTS) Signal Channel"; > > > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > > > o reference: RFC XXXX > > > > > > o This RFC > > > > > > Please update TBD statements with the port number to be assigned t= o > > > DOTS Signal Channel Protocol. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-= 1 > > > 4 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 > > > > > > > > > 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. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 08:51:45 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2EA1241FC for ; Tue, 19 Dec 2017 08:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0anHbeCW9ENf for ; Tue, 19 Dec 2017 08:51:41 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577AF12D7ED for ; Tue, 19 Dec 2017 08:51:41 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513702296; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=r a6vlFCyvWODY9s5xZSndCmWru0NNrIlWazgZ6jfEK Q=; b=qXF/iwnorP8whyu57lJEIN+qtqCARWOIyU63G5kLmdK8 xpQSAgje3xinxKimAL2flrOe6xp5KuhRHvu7l/HbeDUI/jHAUK xNWl1A25XCJs7qkHL5BJcWU+yWdu/oxLZ2RnjC3SPRux5uyR6n pwFL5Tz5fSmSUpPMHQ4m8ox8j10= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 0e1f_bb78_7c0e2c72_2014_4707_8c55_4069c2330966; Tue, 19 Dec 2017 10:51:35 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 11:51:18 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 19 Dec 2017 11:51:18 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 11:51:15 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 16:51:17 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 16:51:16 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQ Date: Tue, 19 Dec 2017 16:51:16 +0000 Message-ID: References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:O6Qiwvq0B8+K5afgqAeZYZ7HAU2klTVD45W22Es8RBKjOJ4Z+AZE28+nc7HtqFGGQYQfaEJMtw65PKYrkw1DceJl14hZ96Xnj2tm10e1JuEJ/80TTgt/VqP3LCoVk5EXTtjxMnK7UxySat8f3kcziFeo+bpN+H4IfE/Y7uyWmE0s4g8GuEmp3j1BoHUyfI1haWyJNouRsh63zQopt9ctfF00QPigKmGbe9cRWu/GNMICBX/Ot+KUj1XjctbVwWI8B45lhUWI6q/7HYcDw1RD83cswyooljjuxpRwDC0DCq2mYO6obabGjHWND508pBiBYTSf9FBHwOrgeoF6I4UVZG9Dw/kFYzlSssqBgatOGuY=; 5:4Ttpi9docZNcMjzjas2lVghb18vL2hWnNi4j4u+BTKc3OOVnXwMCqBgNytvwRtihCnmmIMHOyehA2ibIMivLfF9AEWTRheBxHJDetWW8gn2MSmK+kAo0qsGs1WBTOXTCKMUyDakiJt9xYPGL+8vxx/hjeVn0EMrcFX6q6V3A7Nk=; 24:kJXABcK65f0lKUiy7y89ueu7T9NoykQVfh+hP2fTiUuXBFezbiAuKk9ZgcZrEkYMqEDywJEswek/gFKAnR/koalOGF6TBQdrUcryLzNSpHk=; 7:4n+/nSbMy7HU66MUP1gbYCcm+dc1nKzcjGjLNAS3ayjrPEK8lq/zNrYEdQetWQKKOXAvXKL2ahSDf7CPv+rrqXY3GcCTvdyIttcJwsmD55EaOpVEm86mymLJTorJWz/aXoFkjVOG6+ZefgA/+LSJv5QkBD171RnKampx42RPTQBRE8TPpGHGhgI3vADWKVOGkAk91KNe4QXxDTXgijtD56LNZPPWxdRmFTaLHtPtob66Kjnm32TRTcpzgWmvLgIi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9cf8f915-ff4b-46b9-5ca9-08d54700b8c4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(346002)(32952001)(55784002)(189003)(377424004)(13464003)(199004)(6306002)(53936002)(5660300001)(6246003)(81156014)(4001150100001)(8676002)(7736002)(8936002)(68736007)(6436002)(2501003)(2900100001)(33656002)(230783001)(3660700001)(3280700002)(81166006)(80792005)(53546011)(14454004)(6506007)(72206003)(478600001)(77096006)(74316002)(9686003)(966005)(55016002)(305945005)(97736004)(105586002)(110136005)(2950100002)(7696005)(86362001)(59450400001)(106356001)(99286004)(229853002)(76176011)(6116002)(93886005)(102836003)(316002)(3846002)(2906002)(66066001)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf8f915-ff4b-46b9-5ca9-08d54700b8c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 16:51:16.5309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6183> : inlines <6264> : streams <1773582> : uri <2553900> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 16:51:44 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, December 19, 2017 9:44 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Tiru, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] I= -D > > Action: draft-ietf-dots-signal-channel-14.txt > > > > I don't think the DOTS signal channel draft should enhance the > > functionality of DOTS gateway to aggregate mitigation requests, it's > > not discussed in any of the requirements and architecture drafts. >=20 > [Med] IMO, it is out of the scope of the document to recommend or > preclude this.=20 Agreed.=20 > The main outcome of the discussion is that we don't have > anymore a confusion to interpret the presence of multiple client-ids. The > only provision is when a gateway decides to aggregate. Why and how > aggregation is done is really out of scope. The problem is the draft is now discussing how the DOTS gateway will genera= te multiple client-ids when aggregating mitigation requests from multiple D= OTS clients. It's enhancing the scope of the DOTS gateway to handle a lot m= ore functionality, currently not covered and discussed in the requirements = and architecture drafts.=20 >=20 > > Why should the DOTS server send heartbeat request immediately after > > receiving the heartbeat request from the client, DOTS server anyways > > will send a heartbeat response (CoAP Reset message) for the heartbeat > > request from the client and that will keep the NAT binding alive. >=20 > [Med] The problem is not in that direction. The problem is when the serve= r > sends a heartbeat request to the client but no mapping is found in the > translator/firewall. Sending immediately the probe while the NAT mapping = is > likely to be open will ease nat traversal. This is a MAY. A serever is no= t obliged > to follow it. Yes, I understand but it looks un-necessary on the DOTS server to immediate= ly send a probe. Can you explain a scenario how the client initiated heartb= eat exchange is not sufficient to keep its NAT binding alive ? (see https://tools.ietf.org/html/rfc5245#section-10, keepalives to keep NAT= bindings is unidirectional only and don't invoke a response from the peer)= .=20 >=20 > > Why cannot the client-identifier be generated by client-side DOTS > > gateway (I don't understand the privacy problem, if the > > client-identifier does not reveal the actual DOTS client identity) ? >=20 > [Med] because, e.g., "DOTS server can fully trust the server-side gateway > but cannot fully trust the client-side gateway". Yes, but client-identifier can also be used to detect and resolve collision= (e.g. two DOTS clients using the same alias-name). How will collisions be= handled with this change ? -Tiru >=20 > A network operator can decide to deploy multiple DOTS clients and hide th= e > identity of these clients. To that purpose, it can enable GW in its domai= n to > hide those clients. >=20 > > > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: Tuesday, December 19, 2017 9:05 PM > > > To: dots@ietf.org > > > Subject: Re: [Dots] I-D Action: > > > draft-ietf-dots-signal-channel-14.txt > > > > > > Re-, > > > > > > This version integrates the outcomes of the mailing list discussion, > > > in > > > particular: > > > - Multiple client-id values does not mean anymore that multiple GWs > > > have injected a value each. > > > - Introduce attack-time-config and peace-time-config > > > - Add some text to suggest dots servers to send heartbeats > > > immediately after receiving the one from the peer dots client. > > > - Refreshing the configuration must not occur during attack times. > > > > > > The document is still using client-side and server-side DOTS GW terms= . > > The > > > text will be aligned with the requirements I-D. > > > > > > Jon, please double check. > > > > > > All, please review and share your comments. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0: > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Act= ion: > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > This draft is a work item of the DDoS Open Threat Signaling WG of > > > > the IETF. > > > > > > > > Title : Distributed Denial-of-Service Open Threat > > > > Signaling (DOTS) Signal Channel > > > > Authors : Tirumaleswar Reddy > > > > Mohamed Boucadair > > > > Prashanth Patil > > > > Andrew Mortensen > > > > Nik Teague > > > > Filename : draft-ietf-dots-signal-channel-14.txt > > > > Pages : 84 > > > > Date : 2017-12-19 > > > > > > > > Abstract: > > > > This document specifies the DOTS signal channel, a protocol for > > > > signaling the need for protection against Distributed Denial-of- > > > > Service (DDoS) attacks to a server capable of enabling network > > > > traffic mitigation on behalf of the requesting client. > > > > > > > > A companion document defines the DOTS data channel, a separate > > > > reliable communication layer for DOTS management and configurati= on > > > > purposes. > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > Please update these statements with the RFC number to be > > > > assigned > > to > > > > this document: > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signalin= g > > > > (DOTS) Signal Channel"; > > > > > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > > > > > o reference: RFC XXXX > > > > > > > > o This RFC > > > > > > > > Please update TBD statements with the port number to be assigned > to > > > > DOTS Signal Channel Protocol. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-chann > > > > el-1 > > > > 4 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-= 1 > > > > 4 > > > > > > > > > > > > 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. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 09:27:00 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20D612D94F for ; Tue, 19 Dec 2017 09:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKROaavjENMQ for ; Tue, 19 Dec 2017 09:26:56 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619B812D7F4 for ; Tue, 19 Dec 2017 09:26:56 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRLfJ-0005F3-N7; Tue, 19 Dec 2017 17:26:53 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 19 Dec 2017 17:26:54 -0000 Message-ID: <044d01d378ee$90941610$b1bc4230$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQDAx+IWL3o/zjUSLKzuNis+SDZ2JgDl0/WwAb8UqFkBsmKZiwDikreQpUZ5DGA= Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 17:26:59 -0000 Hi Tiru / Med, See inline [Jon]. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 19 December 2017 16:51 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, December 19, 2017 9:44 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Tiru, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 =C0=A0: BOUCADAIR = Mohamed IMT/OLN;=20 > > dots@ietf.org Objet=A0: RE: [Dots] I-D > > Action: draft-ietf-dots-signal-channel-14.txt > > > > I don't think the DOTS signal channel draft should enhance the=20 > > functionality of DOTS gateway to aggregate mitigation requests, it's = > > not discussed in any of the requirements and architecture drafts. >=20 > [Med] IMO, it is out of the scope of the document to recommend or=20 > preclude this. Agreed.=20 > The main outcome of the discussion is that we don't have anymore a=20 > confusion to interpret the presence of multiple client-ids. The only=20 > provision is when a gateway decides to aggregate. Why and how=20 > aggregation is done is really out of scope. The problem is the draft is now discussing how the DOTS gateway will generate multiple client-ids when aggregating mitigation requests from multiple DOTS clients. It's enhancing the scope of the DOTS gateway to handle a lot more functionality, currently not covered and discussed in = the requirements and architecture drafts.=20 [Jon] As discussed elsewhere, to me aggregation of mitigation-id / alias-name / filter requests is a real challenge and I can only think of = a couple of do-able scenarios out of a lot of different aggregation = scenarios. I am in agreement with you Tiru that aggregation is really all about = session aggregation, but recognize that someone may want to attempt to do this aggregation of mitigation-id / alias-name / filter requests [Jon] I have mentioned in another discussion NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read = (which may be where some of the confusion comes in) Figure 7: Client-Side Gateway with session Aggregation Figure 8: Client-Side Gateway without session Aggregation Figure 9: Server-Side Gateway with session Aggregation Figure 10: Server-Side Gateway without session Aggregation >=20 > > Why should the DOTS server send heartbeat request immediately after=20 > > receiving the heartbeat request from the client, DOTS server anyways = > > will send a heartbeat response (CoAP Reset message) for the=20 > > heartbeat request from the client and that will keep the NAT binding alive. >=20 > [Med] The problem is not in that direction. The problem is when the=20 > server sends a heartbeat request to the client but no mapping is found = > in the translator/firewall. Sending immediately the probe while the=20 > NAT mapping is likely to be open will ease nat traversal. This is a=20 > MAY. A serever is not obliged to follow it. Yes, I understand but it looks un-necessary on the DOTS server to immediately send a probe. Can you explain a scenario how the client initiated heartbeat exchange is not sufficient to keep its NAT binding = alive ? (see https://tools.ietf.org/html/rfc5245#section-10, keepalives to keep = NAT bindings is unidirectional only and don't invoke a response from the = peer). [Jon] If the heartbeat frequency is, say, 10 minutes (a time longer than = the NAT session timeout), and the DOTS server and DOTS client drift in their time to re-transmit, you could end up with the client triggering at time = +0, +10, +20 etc. and the server triggering at +5, +15, +25 etc. When the server comes to transmit its heartbeat, there is no NAT session - and = hence failure. If the DOTS server heartbeat transmission is synchronized to = the DOTS client, then there is no issue with NAT and the requirement that = both server and client transmit heartbeats to network test is fulfilled. [Jon] There is a desire for the heartbeat rate to have long intervals in peace-time - and sending keep-alives at a higher rate to keep NAT "warm" defeats this. =20 >=20 > > Why cannot the client-identifier be generated by client-side DOTS=20 > > gateway (I don't understand the privacy problem, if the=20 > > client-identifier does not reveal the actual DOTS client identity) ? >=20 > [Med] because, e.g., "DOTS server can fully trust the server-side=20 > gateway but cannot fully trust the client-side gateway". Yes, but client-identifier can also be used to detect and resolve = collision (e.g. two DOTS clients using the same alias-name). How will collisions = be handled with this change ? [Jon] If we are NOT adding in defined intelligence to a DOTS gateway as = to how to aggregate mitigation-id/alias-name/filters etc., then the client-identifiers (to me) are the only easy way to avoid collisions = with the names of mitigation-ids, alias-names and filters. Otherwise, the = DOTS gateway will need to "mangle" mitigation-id/alias-name/filters into an unique definition per DOTS client before passing them on upstream. Actually, client-identifier + mitigation-id is an example of the mangled entity... -Tiru >=20 > A network operator can decide to deploy multiple DOTS clients and hide = > the identity of these clients. To that purpose, it can enable GW in=20 > its domain to hide those clients. >=20 > > > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: Tuesday, December 19, 2017 9:05 PM > > > To: dots@ietf.org > > > Subject: Re: [Dots] I-D Action: > > > draft-ietf-dots-signal-channel-14.txt > > > > > > Re-, > > > > > > This version integrates the outcomes of the mailing list=20 > > > discussion, in > > > particular: > > > - Multiple client-id values does not mean anymore that multiple=20 > > > GWs have injected a value each. > > > - Introduce attack-time-config and peace-time-config > > > - Add some text to suggest dots servers to send heartbeats=20 > > > immediately after receiving the one from the peer dots client. > > > - Refreshing the configuration must not occur during attack times. > > > > > > The document is still using client-side and server-side DOTS GW = terms. > > The > > > text will be aligned with the requirements I-D. > > > > > > Jon, please double check. > > > > > > All, please review and share your comments. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de = internet-=20 > > > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 = =C0=A0: > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action: > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > Internet-Drafts directories. > > > > This draft is a work item of the DDoS Open Threat Signaling WG=20 > > > > of the IETF. > > > > > > > > Title : Distributed Denial-of-Service Open = Threat > > > > Signaling (DOTS) Signal Channel > > > > Authors : Tirumaleswar Reddy > > > > Mohamed Boucadair > > > > Prashanth Patil > > > > Andrew Mortensen > > > > Nik Teague > > > > Filename : draft-ietf-dots-signal-channel-14.txt > > > > Pages : 84 > > > > Date : 2017-12-19 > > > > > > > > Abstract: > > > > This document specifies the DOTS signal channel, a protocol = for > > > > signaling the need for protection against Distributed = Denial-of- > > > > Service (DDoS) attacks to a server capable of enabling = network > > > > traffic mitigation on behalf of the requesting client. > > > > > > > > A companion document defines the DOTS data channel, a = separate > > > > reliable communication layer for DOTS management and configuration > > > > purposes. > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > Please update these statements with the RFC number to be=20 > > > > assigned > > to > > > > this document: > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat = Signaling > > > > (DOTS) Signal Channel"; > > > > > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > > > > > o reference: RFC XXXX > > > > > > > > o This RFC > > > > > > > > Please update TBD statements with the port number to be=20 > > > > assigned > to > > > > DOTS Signal Channel Protocol. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-cha > > > > nn > > > > el-1 > > > > 4 > > > > > > > > A diff from the previous version is available at: > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel > > > > -1 > > > > 4 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time=20 > > > > of submission until the htmlized version and diff are available=20 > > > > at tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 13:05:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD56912D869 for ; Tue, 19 Dec 2017 13:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0ZjUW3u0NHU for ; Tue, 19 Dec 2017 13:04:50 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4196F120046 for ; Tue, 19 Dec 2017 13:04:50 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJL16Q1031909; Tue, 19 Dec 2017 16:04:49 -0500 Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0a-00196b01.pphosted.com with ESMTP id 2ew13ncgwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 16:04:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jy5dOuiJ1ORLodmxEoJFb8VeQ0wX0U6QC+FXZHxFICs=; b=hm1ZMKbV80FNKnv7aoYDF1/8DOkeaqL3CvPwCio7+Rju4cLPcg2BkcA4mcIGrFXtF2tKTuqmS1+Z7oUWCG7l62stEZ6S0lsh7jeHa5u2QxjfrxjnxtNa0yVxIs6JQAZd/+YI5QAPlsmo4Xipy4pgSYxUBjlIZZJIIiu6kkRELJo= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 19 Dec 2017 21:04:47 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0302.017; Tue, 19 Dec 2017 21:04:47 +0000 From: "Mortensen, Andrew" To: "mohamed.boucadair@orange.com" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzIZWMp4oi8jkCOjURx20Q43qNKzAeAgABcPYA= Date: Tue, 19 Dec 2017 21:04:47 +0000 Message-ID: References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.136.138.145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1987; 6:hC8LT+F6I+0nhDvRQsqGQjaV5o0rYQONbWLF+CBqs6CQ/735eRBZ35/RzcvMiPgwbvAvFD2jTL0GGHQdWDxHLwI9xD7ct0Xsy80DbPDPM9+DVI3Q9ojUVIsrqP48ZvqyjX1qsryOiOex+VC/4Bc4ip4FuwtIJLz1dIpHDtPb7IYZZvfZIDdUuxiFZmheOlhjFXOXir5psdBA0Ch/yUZw0zdsxqWKxJpeCGaXAzumaUaEPhYLMtualVNLB577RyUGUPc0k0gjSJZO0lvyqLuzW+4vaWpQH3/IDUOjL2mMTxKxRWrNxvgoNGr9rXMNFwsAv+Uhi7b8ltT0QfqULOyKZnMY4HgcuojPOeSdKhliYWA=; 5:2XXPC977uPebrvRW0zFtW+FjGO/SgKAxrxrIOSytBxuBwnF+Wb53SsHpoD8zD7OXGgWp0SX5T+jvmVGwCPQvLZE9PZ/6lw4qWONSsrmyJlCQ7mcbb/272RxG35xCyQVwyluQGY3At5tcGDWbd5KxLoedApDO3Rnki36naZiM04E=; 24:F631R2HFjRWJ+DYCD8jZ77Q3lbbPO7MrWzqvmppnuaKo7NWeyQQOQlvOhAjvffmX2/SdFD3DWihDewZBJs4iA8kT0CIyOgl4JmRp7zaxOrQ=; 7:neaOTixuZzcmmvbdtl7w3aegIPR2u6mjtye0VdDU60h0pu3taz7QM9QHD8jSTdlkOM9qUmyWAhVvIbP9qz0e4GQ2mQLVLlpQmiXywAJvTOGNDCnNbmnWUPM6Q4FFe+Ma8PSBbV4O1vJgva3crgiZDUAwNSvvSFHQ2NsE8tbFPtwpVr0BkUIVZHrp/VjhtF1/TCGJJ7vNwF5ssPCAStOdvDW4kRRHS8kcqG9bVq6FV6KZKsmRzNZoiwmxiFbqu9tj x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4c9619ed-25b1-4991-ff61-08d5472422f6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:BN3PR01MB1987; x-ms-traffictypediagnostic: BN3PR01MB1987: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231023)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:BN3PR01MB1987; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR01MB1987; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(376002)(39860400002)(199004)(189003)(24454002)(6436002)(6916009)(81156014)(81166006)(25786009)(2351001)(66066001)(59450400001)(2501003)(6506007)(106356001)(83716003)(36756003)(2950100002)(8676002)(105586002)(2900100001)(7736002)(76176011)(53546011)(230783001)(99286004)(82746002)(3660700001)(3280700002)(316002)(478600001)(5640700003)(3846002)(77096006)(8936002)(6486002)(102836003)(33656002)(86362001)(6116002)(14454004)(97736004)(5660300001)(2906002)(54896002)(236005)(6246003)(229853002)(6512007)(68736007)(4326008)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1987; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C9775BA88BB244ABAAE7715F7CFCA7B3arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4c9619ed-25b1-4991-ff61-08d5472422f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 21:04:47.1300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1987 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190298 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 21:04:58 -0000 --_000_C9775BA88BB244ABAAE7715F7CFCA7B3arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBNZWQuIE9uZSBjb21tZW50IGFmdGVyIGEgcXVpY2sgc2tpbSBvZiB0aGUgdXBkYXRl ZCBkcmFmdC4NCg0KSeKAmW0gY29uY2VybmVkIGFib3V0IGRlc2lnbmF0aW5nIGF0dGFjay10aW1l IGFuZCBwZWFjZS10aW1lIGNvbmZpZy4gQSBET1RTIGNsaWVudCBpcyBmcmVlIHRvIGRlYWwgd2l0 aCBhIEREb1MgYXR0YWNrIHdpdGhvdXQgcmVxdWVzdGluZyB1cHN0cmVhbSBtaXRpZ2F0aW9uLCBv ciBmb3IgdmFyaW91cyByZWFzb25zIG1heSB3aXRoZHJhdyBhbiBhY3RpdmUgbWl0aWdhdGlvbiBy ZXF1ZXN0IGR1cmluZyBhbiBhdHRhY2suIFRoZSDigJxhdHRhY2stdGltZeKAnSB0ZXJtIHRvIG1l IGltcGxpZXMgc29tZXRoaW5nIGFsd2F5cyB0YWtpbmcgcGxhY2Ugd2hlbiBhbiBhdHRhY2sgaXMg YWN0aXZlLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIERPVFMgY2xpZW50IGhhcyByZXF1ZXN0 IG1pdGlnYXRpb24uIFRoZSBkaXN0aW5jdGlvbiB3ZSB3YW50IHRvIGRyYXcgaXMgcmVhbGx5IGJl dHdlZW4gYSBjb25maWcgZW5hYmxlZCB3aGVuIG1pdGlnYXRpb24gaXMgcmVxdWVzdGVkL2FjdGl2 ZSwgYW5kIHdoZW4gdGhlIGNsaWVudCBoYXMgbm90IHJlcXVlc3RlZCBtaXRpZ2F0aW9uLg0KDQpJ 4oCZbSBub3Qgc3VyZSB3aGF0IHRoZSBiZXN0IHRlcm1pbm9sb2d5IGlzIGZvciB0aGlzIGRpc3Rp bmN0aW9uLiBTb21ldGhpbmcgbGlrZSDigJxpZGxlLWNvbmZpZ+KAnSBhbmQg4oCcbWl0aWdhdGlv bi1jb25maWfigJ0gZ2V0IGNsb3NlciB0byB0aGUgc3Bpcml0IG9mIHdoYXQgSSB0aGluayB3ZSB3 YW50LCB0aG91Z2guDQoNCmFuZHJldw0KDQoNCk9uIERlYyAxOSwgMjAxNywgYXQgMTA6MzQgQU0s IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IHdyb3RlOg0KDQpSZS0sDQoNClRoaXMgdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBv dXRjb21lcyBvZiB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24sIGluIHBhcnRpY3VsYXI6DQot IE11bHRpcGxlIGNsaWVudC1pZCB2YWx1ZXMgZG9lcyBub3QgbWVhbiBhbnltb3JlIHRoYXQgbXVs dGlwbGUgR1dzIGhhdmUgaW5qZWN0ZWQgYSB2YWx1ZSBlYWNoLg0KLSBJbnRyb2R1Y2UgYXR0YWNr LXRpbWUtY29uZmlnIGFuZCBwZWFjZS10aW1lLWNvbmZpZw0KLSBBZGQgc29tZSB0ZXh0IHRvIHN1 Z2dlc3QgZG90cyBzZXJ2ZXJzIHRvIHNlbmQgaGVhcnRiZWF0cyBpbW1lZGlhdGVseSBhZnRlciBy ZWNlaXZpbmcgdGhlIG9uZSBmcm9tIHRoZSBwZWVyIGRvdHMgY2xpZW50Lg0KLSBSZWZyZXNoaW5n IHRoZSBjb25maWd1cmF0aW9uIG11c3Qgbm90IG9jY3VyIGR1cmluZyBhdHRhY2sgdGltZXMuDQoN ClRoZSBkb2N1bWVudCBpcyBzdGlsbCB1c2luZyBjbGllbnQtc2lkZSBhbmQgc2VydmVyLXNpZGUg RE9UUyBHVyB0ZXJtcy4gVGhlIHRleHQgd2lsbCBiZSBhbGlnbmVkIHdpdGggdGhlIHJlcXVpcmVt ZW50cyBJLUQuDQoNCkpvbiwgcGxlYXNlIGRvdWJsZSBjaGVjay4NCg0KQWxsLCBwbGVhc2UgcmV2 aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLg0KDQo= --_000_C9775BA88BB244ABAAE7715F7CFCA7B3arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <0BBD330C78B94D48B2572367083AFB50@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzLCBNZWQuIE9uZSBjb21t ZW50IGFmdGVyIGEgcXVpY2sgc2tpbSBvZiB0aGUgdXBkYXRlZCBkcmFmdC4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPknigJltIGNvbmNlcm5lZCBh Ym91dCBkZXNpZ25hdGluZyBhdHRhY2stdGltZSBhbmQgcGVhY2UtdGltZSBjb25maWcuIEEgRE9U UyBjbGllbnQgaXMgZnJlZSB0byBkZWFsIHdpdGggYSBERG9TIGF0dGFjayB3aXRob3V0IHJlcXVl c3RpbmcgdXBzdHJlYW0gbWl0aWdhdGlvbiwgb3IgZm9yIHZhcmlvdXMgcmVhc29ucyBtYXkgd2l0 aGRyYXcgYW4gYWN0aXZlIG1pdGlnYXRpb24gcmVxdWVzdCBkdXJpbmcgYW4gYXR0YWNrLiBUaGUN CiDigJxhdHRhY2stdGltZeKAnSB0ZXJtIHRvIG1lIGltcGxpZXMgc29tZXRoaW5nIGFsd2F5cyB0 YWtpbmcgcGxhY2Ugd2hlbiBhbiBhdHRhY2sgaXMgYWN0aXZlLCByZWdhcmRsZXNzIG9mIHdoZXRo ZXIgdGhlIERPVFMgY2xpZW50IGhhcyByZXF1ZXN0IG1pdGlnYXRpb24uIFRoZSBkaXN0aW5jdGlv biB3ZSB3YW50IHRvIGRyYXcgaXMgcmVhbGx5IGJldHdlZW4gYSBjb25maWcgZW5hYmxlZCB3aGVu IG1pdGlnYXRpb24gaXMgcmVxdWVzdGVkL2FjdGl2ZSwgYW5kDQogd2hlbiB0aGUgY2xpZW50IGhh cyBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBub3Qgc3VyZSB3aGF0IHRoZSBiZXN0 IHRlcm1pbm9sb2d5IGlzIGZvciB0aGlzIGRpc3RpbmN0aW9uLiBTb21ldGhpbmcgbGlrZSDigJxp ZGxlLWNvbmZpZ+KAnSBhbmQg4oCcbWl0aWdhdGlvbi1jb25maWfigJ0gZ2V0IGNsb3NlciB0byB0 aGUgc3Bpcml0IG9mIHdoYXQgSSB0aGluayB3ZSB3YW50LCB0aG91Z2guPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hbmRyZXc8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxOSwgMjAxNywgYXQgMTA6MzQgQU0sIDxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiBjbGFzcz0iIj4NCm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPlJlLSw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGlzDQogdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBvdXRjb21l cyBvZiB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24sIGluIHBhcnRpY3VsYXI6PC9zcGFuPjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPi0NCiBNdWx0aXBsZSBj bGllbnQtaWQgdmFsdWVzIGRvZXMgbm90IG1lYW4gYW55bW9yZSB0aGF0IG11bHRpcGxlIEdXcyBo YXZlIGluamVjdGVkIGEgdmFsdWUgZWFjaC48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPi0NCiBJbnRyb2R1Y2UgYXR0YWNrLXRpbWUtY29uZmlnIGFuZCBwZWFjZS10 aW1lLWNvbmZpZzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz cz0iIj4tDQogQWRkIHNvbWUgdGV4dCB0byBzdWdnZXN0IGRvdHMgc2VydmVycyB0byBzZW5kIGhl YXJ0YmVhdHMgaW1tZWRpYXRlbHkgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBvbmUgZnJvbSB0aGUgcGVl ciBkb3RzIGNsaWVudC48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pi0NCiBSZWZyZXNoaW5nIHRoZSBjb25maWd1cmF0aW9uIG11c3Qgbm90IG9jY3VyIGR1cmluZyBh dHRhY2sgdGltZXMuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5UaGUNCiBkb2N1bWVudCBpcyBzdGlsbCB1c2luZyBjbGllbnQtc2lkZSBh bmQgc2VydmVyLXNpZGUgRE9UUyBHVyB0ZXJtcy4gVGhlIHRleHQgd2lsbCBiZSBhbGlnbmVkIHdp dGggdGhlIHJlcXVpcmVtZW50cyBJLUQuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyIgY2xhc3M9IiI+Sm9uLA0KIHBsZWFzZSBkb3VibGUgY2hlY2suPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkFsbCwNCiBwbGVhc2UgcmV2aWV3 IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C9775BA88BB244ABAAE7715F7CFCA7B3arbornet_-- From nobody Tue Dec 19 13:22:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BBB12D85F for ; Tue, 19 Dec 2017 13:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMTOwcn82E6V for ; Tue, 19 Dec 2017 13:22:11 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3864F12D84C for ; Tue, 19 Dec 2017 13:22:11 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRPKy-0005MX-VP; Tue, 19 Dec 2017 21:22:09 +0000 From: "Jon Shallow" To: "'Mortensen, Andrew'" , , References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 19 Dec 2017 21:22:09 -0000 Message-ID: <048901d3790f$6dd48170$497d8450$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_048A_01D3790F.6DD6F270" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQDAx+IWL3o/zjUSLKzuNis+SDZ2JgDl0/WwAY9VnpKlXOVvMA== Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 21:22:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_048A_01D3790F.6DD6F270 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, =20 Does =E2=80=9Cidle-config=E2=80=9D and = =E2=80=9Cmitigating-config=E2=80=9D work for you? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew Sent: 19 December 2017 21:05 To: mohamed.boucadair@orange.com Cc: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt =20 Thanks, Med. One comment after a quick skim of the updated draft.=20 =20 I=E2=80=99m concerned about designating attack-time and peace-time = config. A DOTS client is free to deal with a DDoS attack without = requesting upstream mitigation, or for various reasons may withdraw an = active mitigation request during an attack. The = =E2=80=9Cattack-time=E2=80=9D term to me implies something always taking = place when an attack is active, regardless of whether the DOTS client = has request mitigation. The distinction we want to draw is really = between a config enabled when mitigation is requested/active, and when = the client has not requested mitigation. =20 I=E2=80=99m not sure what the best terminology is for this distinction. = Something like =E2=80=9Cidle-config=E2=80=9D and = =E2=80=9Cmitigation-config=E2=80=9D get closer to the spirit of what I = think we want, though. =20 andrew =20 =20 On Dec 19, 2017, at 10:34 AM, mohamed.boucadair@orange.com wrote: =20 Re-, This version integrates the outcomes of the mailing list discussion, in = particular: - Multiple client-id values does not mean anymore that multiple GWs have = injected a value each.=20 - Introduce attack-time-config and peace-time-config - Add some text to suggest dots servers to send heartbeats immediately = after receiving the one from the peer dots client.=20 - Refreshing the configuration must not occur during attack times.=20 The document is still using client-side and server-side DOTS GW terms. = The text will be aligned with the requirements I-D. Jon, please double check.=20 All, please review and share your comments. =20 ------=_NextPart_000_048A_01D3790F.6DD6F270 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

Does =E2=80=9Cidle-config=E2=80=9D and = =E2=80=9Cmitigating-config=E2=80=9D work for = you?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew
Sent: 19 December 2017 21:05
To: = mohamed.boucadair@orange.com
Cc: = dots@ietf.org
Subject: Re: [Dots] I-D Action: = draft-ietf-dots-signal-channel-14.txt

 

Thanks, = Med. One comment after a quick skim of the updated draft. =

 

I=E2=80=99m concerned about designating attack-time = and peace-time config. A DOTS client is free to deal with a DDoS attack = without requesting upstream mitigation, or for various reasons may = withdraw an active mitigation request during an attack. The = =E2=80=9Cattack-time=E2=80=9D term to me implies something always taking = place when an attack is active, regardless of whether the DOTS client = has request mitigation. The distinction we want to draw is really = between a config enabled when mitigation is requested/active, and when = the client has not requested mitigation.

 

I=E2=80=99m not sure what the best terminology is for = this distinction. Something like =E2=80=9Cidle-config=E2=80=9D and = =E2=80=9Cmitigation-config=E2=80=9D get closer to the spirit of what I = think we want, though.

 

andrew

 

 

On Dec 19, 2017, at 10:34 AM, mohamed.boucadair@orange.com= wrote:

 

Re-,
This version integrates the outcomes of the mailing list discussion, = in particular:
- Multiple client-id values does not mean anymore that = multiple GWs have injected a value each. 
- Introduce = attack-time-config and peace-time-config
- Add some text to suggest = dots servers to send heartbeats immediately after receiving the one from = the peer dots client. 
- Refreshing the = configuration must not occur during attack times. 


The = document is still using client-side and server-side DOTS GW terms. The = text will be aligned with the requirements I-D.

Jon, please = double check. 

All, please review = and share your = comments.

 

------=_NextPart_000_048A_01D3790F.6DD6F270-- From nobody Tue Dec 19 13:41:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DE512D856 for ; Tue, 19 Dec 2017 13:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0qhfKvmLdqb for ; Tue, 19 Dec 2017 13:41:48 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14E71200FC for ; Tue, 19 Dec 2017 13:41:48 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJLfOl4027255; Tue, 19 Dec 2017 16:41:48 -0500 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0052.outbound.protection.outlook.com [207.46.163.52]) by mx0a-00196b01.pphosted.com with ESMTP id 2ew0gu4mvr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 16:41:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d6b2Jg4ApxcWeQ+vEcBDhSGbyST31dfvqHvaFnQmAo4=; b=mCMiG0npo+PwlKrX5gQYj2sqXPdFFqepcOy68CNl7962qoUGhphu0QUo5u67U7HjFujXcAeD2HkvMB5yd5WdwAyMzlg0ezpUAPAOUI87/Fy+7pk0/2PRS7AnWvnaILPuBx7P/nwNt8wJ7vcxv2bnVvSxEA/hDhgj+cCXS1izEX8= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1988.prod.exchangelabs.com (10.166.71.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 19 Dec 2017 21:41:46 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0302.017; Tue, 19 Dec 2017 21:41:46 +0000 From: "Mortensen, Andrew" To: Jon Shallow CC: dots , "mohamed.boucadair@orange.com" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzIZWMp4oi8jkCOjURx20Q43qNKzAeAgABcPYCAAATdgIAABXgA Date: Tue, 19 Dec 2017 21:41:46 +0000 Message-ID: <07A9F5E9-03B4-4875-8FB9-B72B8C3FFAD2@arbor.net> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <048901d3790f$6dd48170$497d8450$@jpshallow.com> In-Reply-To: <048901d3790f$6dd48170$497d8450$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.136.138.145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1988; 6:drYTjFJ4l6CpQssc1a2+FNr/LdbWviLgijaklJmaLiaP5c1DpyD1R87Xoxi0oLrDYAvKI7PYAEqzQFxtNZa5dhzmYQ7H5amxU6qU7poWsn8XqMJSheO0Tcu+Ytl3wUVM4rVA3ZH0mzITaSeIfBl5jkRCYg3oQxsNb1LEz3EyxEufI9vbOskc3m5DtwD9vTXfpajch85lPv27VJZ7jbhSflcG8Vp4iUjnPsilGzcAdZ2sGoj/I6neRz0ZA5UcO2acQR6DRv3q0llf/eIWUVxJTF8D6sl3424OjO5p8mIqRMjtReREijpwv9Dla/MEls6+WUsHvDaReBSpSyWNEVMs0KiinMY5iGBhCTnLFaw8RD4=; 5:XjPrhBy9Y5TVjrdn61EwJKocm9Jp94jCC3MzZlj81a9alG8KYFIGdsZSUpLpomqXQC+db+Vycoly1CaYyMyukkfEM+2wpR2NuQU5/jTjLl15uA4w7NQwjHxCrE6uYPKHS5BeayJq6xIaac3xbvWvx3/eMYXi2bYUaPYt0KTMPi0=; 24:uDyW6GeUa3UzwuEFhnD8K5OZpYUnDbafgzQTPbMqXAbT6E4cCgjz2iljDsbRH2XDJCh9IqvK+v26jZlivrsi2nBwyQ0L3PvYKMYuU9r4ufM=; 7:2bN1VHwE9Yn13xhn2DlqSsqc4ul2KNET2Trx4c23RQnru0jovNcypc9B8k+a83zCMm1NiFKKYQ1d7TPcZfpM+MkUEGz5d8jAILZ9rO1k/A2odkr+YR5jfehzkKJyoR4QOxQD9hJc6PtfhS87iEiZlQRA+Vs2Vz8jZNIxolyOBZKeiqk93PYenGlWCBkFyFiP/8fvgrFHuEF0FnN2AYCZTUaugiZbpH99U72b0u5VIx2ZtwGvRGHYGSSpfq9+GJBh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c5380a50-576f-4483-7bc9-08d547294d96 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:BN3PR01MB1988; x-ms-traffictypediagnostic: BN3PR01MB1988: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011); SRVR:BN3PR01MB1988; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR01MB1988; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39860400002)(366004)(24454002)(199004)(189003)(6486002)(229853002)(478600001)(5660300001)(93886005)(33656002)(68736007)(53936002)(54896002)(82746002)(66066001)(83716003)(2950100002)(6246003)(14454004)(8936002)(6512007)(99286004)(6436002)(76176011)(236005)(4326008)(230783001)(36756003)(316002)(81156014)(3660700001)(81166006)(6916009)(3846002)(105586002)(77096006)(2906002)(6506007)(3280700002)(6116002)(59450400001)(106356001)(8676002)(7736002)(53546011)(102836003)(2900100001)(97736004)(54906003)(86362001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1988; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_07A9F5E903B448758FB9B72B8C3FFAD2arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: c5380a50-576f-4483-7bc9-08d547294d96 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 21:41:46.2482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1988 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190307 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 21:41:51 -0000 --_000_07A9F5E903B448758FB9B72B8C3FFAD2arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBEZWMgMTksIDIwMTcsIGF0IDQ6MjIgUE0sIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6DQoN CkhpIEFuZHJldywNCg0KRG9lcyDigJxpZGxlLWNvbmZpZ+KAnSBhbmQg4oCcbWl0aWdhdGluZy1j b25maWfigJ0gd29yayBmb3IgeW91Pw0KDQpUaGV5IGRvLg0KDQphbmRyZXcNCg0KDQoNCg0KRnJv bTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNb3J0ZW5zZW4sIEFuZHJldw0KU2VudDogMTkgRGVj ZW1iZXIgMjAxNyAyMTowNQ0KVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpDYzogZG90c0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwt MTQudHh0DQoNClRoYW5rcywgTWVkLiBPbmUgY29tbWVudCBhZnRlciBhIHF1aWNrIHNraW0gb2Yg dGhlIHVwZGF0ZWQgZHJhZnQuDQoNCknigJltIGNvbmNlcm5lZCBhYm91dCBkZXNpZ25hdGluZyBh dHRhY2stdGltZSBhbmQgcGVhY2UtdGltZSBjb25maWcuIEEgRE9UUyBjbGllbnQgaXMgZnJlZSB0 byBkZWFsIHdpdGggYSBERG9TIGF0dGFjayB3aXRob3V0IHJlcXVlc3RpbmcgdXBzdHJlYW0gbWl0 aWdhdGlvbiwgb3IgZm9yIHZhcmlvdXMgcmVhc29ucyBtYXkgd2l0aGRyYXcgYW4gYWN0aXZlIG1p dGlnYXRpb24gcmVxdWVzdCBkdXJpbmcgYW4gYXR0YWNrLiBUaGUg4oCcYXR0YWNrLXRpbWXigJ0g dGVybSB0byBtZSBpbXBsaWVzIHNvbWV0aGluZyBhbHdheXMgdGFraW5nIHBsYWNlIHdoZW4gYW4g YXR0YWNrIGlzIGFjdGl2ZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBET1RTIGNsaWVudCBo YXMgcmVxdWVzdCBtaXRpZ2F0aW9uLiBUaGUgZGlzdGluY3Rpb24gd2Ugd2FudCB0byBkcmF3IGlz IHJlYWxseSBiZXR3ZWVuIGEgY29uZmlnIGVuYWJsZWQgd2hlbiBtaXRpZ2F0aW9uIGlzIHJlcXVl c3RlZC9hY3RpdmUsIGFuZCB3aGVuIHRoZSBjbGllbnQgaGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdh dGlvbi4NCg0KSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUgYmVzdCB0ZXJtaW5vbG9neSBpcyBmb3Ig dGhpcyBkaXN0aW5jdGlvbi4gU29tZXRoaW5nIGxpa2Ug4oCcaWRsZS1jb25maWfigJ0gYW5kIOKA nG1pdGlnYXRpb24tY29uZmln4oCdIGdldCBjbG9zZXIgdG8gdGhlIHNwaXJpdCBvZiB3aGF0IEkg dGhpbmsgd2Ugd2FudCwgdGhvdWdoLg0KDQphbmRyZXcNCg0KDQpPbiBEZWMgMTksIDIwMTcsIGF0 IDEwOjM0IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KUmUtLA0KDQpUaGlzIHZlcnNpb24gaW50ZWdy YXRlcyB0aGUgb3V0Y29tZXMgb2YgdGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLCBpbiBwYXJ0 aWN1bGFyOg0KLSBNdWx0aXBsZSBjbGllbnQtaWQgdmFsdWVzIGRvZXMgbm90IG1lYW4gYW55bW9y ZSB0aGF0IG11bHRpcGxlIEdXcyBoYXZlIGluamVjdGVkIGEgdmFsdWUgZWFjaC4NCi0gSW50cm9k dWNlIGF0dGFjay10aW1lLWNvbmZpZyBhbmQgcGVhY2UtdGltZS1jb25maWcNCi0gQWRkIHNvbWUg dGV4dCB0byBzdWdnZXN0IGRvdHMgc2VydmVycyB0byBzZW5kIGhlYXJ0YmVhdHMgaW1tZWRpYXRl bHkgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBvbmUgZnJvbSB0aGUgcGVlciBkb3RzIGNsaWVudC4NCi0g UmVmcmVzaGluZyB0aGUgY29uZmlndXJhdGlvbiBtdXN0IG5vdCBvY2N1ciBkdXJpbmcgYXR0YWNr IHRpbWVzLg0KDQpUaGUgZG9jdW1lbnQgaXMgc3RpbGwgdXNpbmcgY2xpZW50LXNpZGUgYW5kIHNl cnZlci1zaWRlIERPVFMgR1cgdGVybXMuIFRoZSB0ZXh0IHdpbGwgYmUgYWxpZ25lZCB3aXRoIHRo ZSByZXF1aXJlbWVudHMgSS1ELg0KDQpKb24sIHBsZWFzZSBkb3VibGUgY2hlY2suDQoNCkFsbCwg cGxlYXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21tZW50cy4NCg0K --_000_07A9F5E903B448758FB9B72B8C3FFAD2arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <1154531054B2C040BF0DF72A0D5DB17E@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMg MTksIDIwMTcsIGF0IDQ6MjIgUE0sIEpvbiBTaGFsbG93ICZsdDs8YSBocmVmPSJtYWlsdG86c3Vw anBzLWlldGZAanBzaGFsbG93LmNvbSIgY2xhc3M9IiI+c3VwanBzLWlldGZAanBzaGFsbG93LmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJw YWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5IaSBBbmRyZXcsPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+RG9lcyDigJxpZGxlLWNvbmZpZ+KAnSBhbmQg4oCcbWl0aWdhdGlu Zy1jb25maWfigJ0gd29yayBmb3IgeW91Pzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGV5IGRvLjwv ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+YW5kcmV3PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi IHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlk IG5vbmUgbm9uZTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2Io MTgxLCAxOTYsIDIyMyk7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+RG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9y ZyIgY2xhc3M9IiI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+T24gQmVoYWxmIE9mPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Nb3J0ZW5z ZW4sIEFuZHJldzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4xOSBEZWNlbWJlciAyMDE3IDIx OjA1PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSIgY2xhc3M9IiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRvdHNAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2ln bmFsLWNoYW5uZWwtMTQudHh0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhhbmtzLCBNZWQuIE9uZSBjb21tZW50IGFm dGVyIGEgcXVpY2sgc2tpbSBvZiB0aGUgdXBkYXRlZCBkcmFmdC48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQpJ4oCZbSBjb25jZXJuZWQgYWJvdXQgZGVzaWduYXRpbmcgYXR0YWNrLXRpbWUgYW5kIHBlYWNl LXRpbWUgY29uZmlnLiBBIERPVFMgY2xpZW50IGlzIGZyZWUgdG8gZGVhbCB3aXRoIGEgRERvUyBh dHRhY2sgd2l0aG91dCByZXF1ZXN0aW5nIHVwc3RyZWFtIG1pdGlnYXRpb24sIG9yIGZvciB2YXJp b3VzIHJlYXNvbnMgbWF5IHdpdGhkcmF3IGFuIGFjdGl2ZSBtaXRpZ2F0aW9uIHJlcXVlc3QgZHVy aW5nIGFuIGF0dGFjay4gVGhlIOKAnGF0dGFjay10aW1l4oCdDQogdGVybSB0byBtZSBpbXBsaWVz IHNvbWV0aGluZyBhbHdheXMgdGFraW5nIHBsYWNlIHdoZW4gYW4gYXR0YWNrIGlzIGFjdGl2ZSwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBET1RTIGNsaWVudCBoYXMgcmVxdWVzdCBtaXRpZ2F0 aW9uLiBUaGUgZGlzdGluY3Rpb24gd2Ugd2FudCB0byBkcmF3IGlzIHJlYWxseSBiZXR3ZWVuIGEg Y29uZmlnIGVuYWJsZWQgd2hlbiBtaXRpZ2F0aW9uIGlzIHJlcXVlc3RlZC9hY3RpdmUsIGFuZCB3 aGVuIHRoZSBjbGllbnQNCiBoYXMgbm90IHJlcXVlc3RlZCBtaXRpZ2F0aW9uLjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpJ4oCZbSBub3Qgc3VyZSB3aGF0IHRoZSBiZXN0IHRl cm1pbm9sb2d5IGlzIGZvciB0aGlzIGRpc3RpbmN0aW9uLiBTb21ldGhpbmcgbGlrZSDigJxpZGxl LWNvbmZpZ+KAnSBhbmQg4oCcbWl0aWdhdGlvbi1jb25maWfigJ0gZ2V0IGNsb3NlciB0byB0aGUg c3Bpcml0IG9mIHdoYXQgSSB0aGluayB3ZSB3YW50LCB0aG91Z2guPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCmFuZHJldzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIiB0 eXBlPSJjaXRlIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gRGVjIDE5LCAyMDE3LCBhdCAxMDozNCBBTSw8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pndyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5SZS0sPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhpcyB2ZXJzaW9uIGludGVncmF0ZXMgdGhlIG91dGNvbWVzIG9mIHRo ZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiwgaW4gcGFydGljdWxhcjo8YnIgY2xhc3M9IiI+DQot IE11bHRpcGxlIGNsaWVudC1pZCB2YWx1ZXMgZG9lcyBub3QgbWVhbiBhbnltb3JlIHRoYXQgbXVs dGlwbGUgR1dzIGhhdmUgaW5qZWN0ZWQgYSB2YWx1ZSBlYWNoLjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQotIEludHJvZHVjZSBh dHRhY2stdGltZS1jb25maWcgYW5kIHBlYWNlLXRpbWUtY29uZmlnPGJyIGNsYXNzPSIiPg0KLSBB ZGQgc29tZSB0ZXh0IHRvIHN1Z2dlc3QgZG90cyBzZXJ2ZXJzIHRvIHNlbmQgaGVhcnRiZWF0cyBp bW1lZGlhdGVseSBhZnRlciByZWNlaXZpbmcgdGhlIG9uZSBmcm9tIHRoZSBwZWVyIGRvdHMgY2xp ZW50LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIg Y2xhc3M9IiI+DQotIFJlZnJlc2hpbmcgdGhlIGNvbmZpZ3VyYXRpb24gbXVzdCBub3Qgb2NjdXIg ZHVyaW5nIGF0dGFjayB0aW1lcy48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1i b3R0b206IDVwdDsiIGNsYXNzPSIiIHR5cGU9ImNpdGUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQpUaGUgZG9jdW1lbnQgaXMgc3RpbGwgdXNpbmcgY2xpZW50LXNp ZGUgYW5kIHNlcnZlci1zaWRlIERPVFMgR1cgdGVybXMuIFRoZSB0ZXh0IHdpbGwgYmUgYWxpZ25l ZCB3aXRoIHRoZSByZXF1aXJlbWVudHMgSS1ELjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkpvbiwgcGxlYXNlIGRvdWJsZSBjaGVjay48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWxsLCBwbGVh c2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_07A9F5E903B448758FB9B72B8C3FFAD2arbornet_-- From nobody Tue Dec 19 19:24:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48172124D85 for ; Tue, 19 Dec 2017 19:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVo7GaO0shBz for ; Tue, 19 Dec 2017 19:24:10 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC593124205 for ; Tue, 19 Dec 2017 19:24:09 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513740248; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=EAdon6kGfmb5nBhQe1Uc7JX7eMzrZox/kSNPTQ 521ks=; b=N6E7EB0CkUWtPpUGEq6UhyCoWVJPzPc6XgQrvjQ8 f16FSYfa2vopcLJ/1pr90kkbFsQpkz8gOt3tRyWRV1DiNb8w7S 1ZIMIs4k517OzrojvknwlMYNW12Cpv2cMVIQV2OZ60c1NEeQVR Aliub+5uGx5cXKtA8hHaS7QoCsQsk7k= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 4b6f_0eda_c8966fcd_b05b_44ab_b56e_128ed7851f90; Tue, 19 Dec 2017 21:24:08 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 22:24:07 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 22:24:06 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 19 Dec 2017 22:24:06 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 22:24:05 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Wed, 20 Dec 2017 03:24:03 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Wed, 20 Dec 2017 03:24:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQgAAT5QCAAJ3ZgA== Date: Wed, 20 Dec 2017 03:24:03 +0000 Message-ID: References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <044d01d378ee$90941610$b1bc4230$@jpshallow.com> In-Reply-To: <044d01d378ee$90941610$b1bc4230$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:CLda9v3gZRIZK2mOnYDwO0d7kQajiQXY02rMYDwGiVLPaB4tCibhyuiJZRvSJ8dqlaHY7oOhwyV0xdCsjiC2ja1QncUi3TgAr71qfd09QHMLKxYr0qUQskuq0YX0S0Wwj1TEVD3AcLvjfb5nY1ZRLFcymEs4gLXi180vR94hn0w3bFrchEn7IsGQ40EiHb8g5O3Pw/f0vuGzwoQ50w1fgwbvpqck/3KAsqRfnh+8Caep2+SD9YX5cUvD+xKZ2LYAJ2NHZPhy90wUKpHB3nxoX3FgCtE17tylI7FwAQxVJ5vwHZ8ZmiEkY++SfrRyCHqGGKIQB8bGd3ywosZryITJ9Ax7Pg0WDIYVeaZ2SO3erzM=; 5:t5/Td51AfdLHuNuoegosxsyIphlkgIRpOhS7NJW54tugb5MkwQqkUmZIzgZGyKDcFGEQaSFHKqub1ctYbZBE5ZOcK1Z/DXfB1ZUS7GbLwKmVIBCCzTumtKLwdb5CG5a6JFF2AJoj0+zlSgkDdjbWi3kfGzUocapHyUFLKuFTyoI=; 24:Tnto/fk8dPsr8xMyMX7j0sWKLN0cFCB+esdJrW5uwoVIsJFByQYJkwgrWxAxJRljFmlzCidRxshziOFhw9WmGHp/afJgh/42D8Jdp5EQEK0=; 7:OGaPo0+uPrUjOXz4ysKEe/hmA5WZE9yT6r/GY9MXIEjW7UkYkoTl/a0BfvO+TxOYTvyNTI+hRDJ8t7aEfHtXLb8A0Gk0oEKZvv37o/liUmmhc3aubdrPGJldhwmwHZmTeYeE51DeUti5yuvdneSkREMPsRrI+Bkw6JTwv03p5RqiuB5TOkFMtogkCSTyKanzNyFQh1vroCA1J1yoAG/BJFlzpx3kG/tDjq6+/ECHjEBlJpmOtwQBeQsj4SxP/2k0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 72ab832b-5787-4c80-265d-08d547591e9f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231023)(901003)(3002001)(6041268)(201703131423095)(201703061421075)(201703161042150)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(6042181)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(189003)(199004)(55784002)(377424004)(13464003)(32952001)(86362001)(14454004)(7696005)(3660700001)(3280700002)(99286004)(6306002)(55016002)(80792005)(9686003)(4001150100001)(2906002)(53936002)(2201001)(59450400001)(105586002)(6436002)(106356001)(110136005)(72206003)(966005)(6506007)(53546011)(97736004)(66066001)(76176011)(33656002)(5660300001)(77096006)(230783001)(2501003)(229853002)(305945005)(7736002)(498600001)(74316002)(68736007)(8676002)(81166006)(81156014)(93886005)(3846002)(102836003)(6116002)(25786009)(2950100002)(6246003)(2900100001)(8936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72ab832b-5787-4c80-265d-08d547591e9f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 03:24:03.2482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6183> : inlines <6267> : streams <1773623> : uri <2554148> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 03:24:13 -0000 Hi Jon, Please see inline > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, December 19, 2017 10:57 PM > To: Konda, Tirumaleswar Reddy > ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Tiru / Med, >=20 > See inline [Jon]. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 19 December 2017 16:51 > To: mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, December 19, 2017 9:44 PM > > To: Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > Hi Tiru, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 =C0=A0: BOUCADAIR Mohamed > IMT/OLN; > > > dots@ietf.org Objet=A0: RE: [Dots] I-D > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > I don't think the DOTS signal channel draft should enhance the > > > functionality of DOTS gateway to aggregate mitigation requests, it's > > > not discussed in any of the requirements and architecture drafts. > > > > [Med] IMO, it is out of the scope of the document to recommend or > > preclude this. >=20 > Agreed. >=20 > > The main outcome of the discussion is that we don't have anymore a > > confusion to interpret the presence of multiple client-ids. The only > > provision is when a gateway decides to aggregate. Why and how > > aggregation is done is really out of scope. >=20 > The problem is the draft is now discussing how the DOTS gateway will > generate multiple client-ids when aggregating mitigation requests from > multiple DOTS clients. It's enhancing the scope of the DOTS gateway to > handle a lot more functionality, currently not covered and discussed in t= he > requirements and architecture drafts. >=20 > [Jon] As discussed elsewhere, to me aggregation of mitigation-id / alias- > name / filter requests is a real challenge and I can only think of a coup= le of > do-able scenarios out of a lot of different aggregation scenarios. > I am in agreement with you Tiru that aggregation is really all about sess= ion > aggregation, but recognize that someone may want to attempt to do this > aggregation of mitigation-id / alias-name / filter requests=20 Agreed. DOTS architecture draft should be updated to clarify the scope of a= ggregation is only at session level and=20 remove text from the DOTS signal channel draft discussing aggregation of mi= tigation requests. > [Jon] I have > mentioned in another discussion > NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (wh= ich > may be where some of the confusion comes in) Figure 7: Client-Side > Gateway with session Aggregation Figure 8: Client-Side Gateway without > session Aggregation Figure 9: Server-Side Gateway with session Aggregatio= n > Figure 10: Server-Side Gateway without session Aggregation >=20 > > > > > Why should the DOTS server send heartbeat request immediately after > > > receiving the heartbeat request from the client, DOTS server anyways > > > will send a heartbeat response (CoAP Reset message) for the > > > heartbeat request from the client and that will keep the NAT binding > alive. > > > > [Med] The problem is not in that direction. The problem is when the > > server sends a heartbeat request to the client but no mapping is found > > in the translator/firewall. Sending immediately the probe while the > > NAT mapping is likely to be open will ease nat traversal. This is a > > MAY. A serever is not obliged to follow it. >=20 > Yes, I understand but it looks un-necessary on the DOTS server to > immediately send a probe. Can you explain a scenario how the client initi= ated > heartbeat exchange is not sufficient to keep its NAT binding alive ? > (see https://tools.ietf.org/html/rfc5245#section-10, keepalives to keep N= AT > bindings is unidirectional only and don't invoke a response from the peer= ). >=20 > [Jon] If the heartbeat frequency is, say, 10 minutes (a time longer than = the > NAT session timeout), and the DOTS server and DOTS client drift in their = time > to re-transmit, you could end up with the client triggering at time +0, > +10, +20 etc. and the server triggering at +5, +15, +25 etc. When the > server comes to transmit its heartbeat, there is no NAT session - and hen= ce > failure. If the DOTS server heartbeat transmission is synchronized to th= e > DOTS client, then there is no issue with NAT and the requirement that bot= h > server and client transmit heartbeats to network test is fulfilled. If the heartbeat frequency is higher than the NAT session timeout, the hear= tbeat request packet from the DOTS client could get a different public sour= ce IP address and/or a different public source port allocated by NAT and th= e packet will be rejected by the DOTS server (no corresponding DTLS state a= ssociated with the 5-tuple).=20 It is the responsibility of the DOTS client to maintain its NAT binding and= not the problem of the DOTS server. =20 > [Jon] There is a desire for the heartbeat rate to have long intervals in = peace- > time - and sending keep-alives at a higher rate to keep NAT "warm" > defeats this. >=20 > > > > > Why cannot the client-identifier be generated by client-side DOTS > > > gateway (I don't understand the privacy problem, if the > > > client-identifier does not reveal the actual DOTS client identity) ? > > > > [Med] because, e.g., "DOTS server can fully trust the server-side > > gateway but cannot fully trust the client-side gateway". >=20 > Yes, but client-identifier can also be used to detect and resolve collisi= on (e.g. > two DOTS clients using the same alias-name). How will collisions be hand= led > with this change ? >=20 > [Jon] If we are NOT adding in defined intelligence to a DOTS gateway as t= o > how to aggregate mitigation-id/alias-name/filters etc., then the client- > identifiers (to me) are the only easy way to avoid collisions with the na= mes of > mitigation-ids, alias-names and filters. Otherwise, the DOTS gateway wil= l > need to "mangle" mitigation-id/alias-name/filters into an unique definiti= on > per DOTS client before passing them on upstream. > Actually, client-identifier + mitigation-id is an example of the mangled = entity... Agreed, the text needs to reverted back to allow both client-side and serve= r-side gateways to add/update client-identifier.=20 Cheers, -Tiru >=20 > -Tiru >=20 > > > > A network operator can decide to deploy multiple DOTS clients and hide > > the identity of these clients. To that purpose, it can enable GW in > > its domain to hide those clients. > > > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: Tuesday, December 19, 2017 9:05 PM > > > > To: dots@ietf.org > > > > Subject: Re: [Dots] I-D Action: > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > Re-, > > > > > > > > This version integrates the outcomes of the mailing list > > > > discussion, in > > > > particular: > > > > - Multiple client-id values does not mean anymore that multiple > > > > GWs have injected a value each. > > > > - Introduce attack-time-config and peace-time-config > > > > - Add some text to suggest dots servers to send heartbeats > > > > immediately after receiving the one from the peer dots client. > > > > - Refreshing the configuration must not occur during attack times. > > > > > > > > The document is still using client-side and server-side DOTS GW ter= ms. > > > The > > > > text will be aligned with the requirements I-D. > > > > > > > > Jon, please double check. > > > > > > > > All, please review and share your comments. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet= - > > > > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0= =A0: > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D A= ction: > > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. > > > > > This draft is a work item of the DDoS Open Threat Signaling WG > > > > > of the IETF. > > > > > > > > > > Title : Distributed Denial-of-Service Open Thre= at > > > > > Signaling (DOTS) Signal Channel > > > > > Authors : Tirumaleswar Reddy > > > > > Mohamed Boucadair > > > > > Prashanth Patil > > > > > Andrew Mortensen > > > > > Nik Teague > > > > > Filename : draft-ietf-dots-signal-channel-14.txt > > > > > Pages : 84 > > > > > Date : 2017-12-19 > > > > > > > > > > Abstract: > > > > > This document specifies the DOTS signal channel, a protocol fo= r > > > > > signaling the need for protection against Distributed Denial-o= f- > > > > > Service (DDoS) attacks to a server capable of enabling network > > > > > traffic mitigation on behalf of the requesting client. > > > > > > > > > > A companion document defines the DOTS data channel, a separate > > > > > reliable communication layer for DOTS management and > configuration > > > > > purposes. > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > Please update these statements with the RFC number to be > > > > > assigned > > > to > > > > > this document: > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signal= ing > > > > > (DOTS) Signal Channel"; > > > > > > > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > o This RFC > > > > > > > > > > Please update TBD statements with the port number to be > > > > > assigned > > to > > > > > DOTS Signal Channel Protocol. > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-cha > > > > > nn > > > > > el-1 > > > > > 4 > > > > > > > > > > A diff from the previous version is available at: > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channe= l > > > > > -1 > > > > > 4 > > > > > > > > > > > > > > > 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. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 23:11:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C462126DEE for ; Tue, 19 Dec 2017 23:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpikwri-5q_V for ; Tue, 19 Dec 2017 23:11:05 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86643126D3F for ; Tue, 19 Dec 2017 23:11:05 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id D8C6560BB0; Wed, 20 Dec 2017 08:11:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id BAB8D16005F; Wed, 20 Dec 2017 08:11:03 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 08:11:03 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQgAADIgCAAKbXgIAAQuPQ Date: Wed, 20 Dec 2017 07:11:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09B298@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <044d01d378ee$90941610$b1bc4230$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 07:11:09 -0000 Hi Tiru,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 04:24 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Jon, >=20 > Please see inline >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Tuesday, December 19, 2017 10:57 PM > > To: Konda, Tirumaleswar Reddy > > ; > > mohamed.boucadair@orange.com; dots@ietf.org > > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > Hi Tiru / Med, > > > > See inline [Jon]. > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > Tirumaleswar Reddy > > Sent: 19 December 2017 16:51 > > To: mohamed.boucadair@orange.com; dots@ietf.org > > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Tuesday, December 19, 2017 9:44 PM > > > To: Konda, Tirumaleswar Reddy > > > ; dots@ietf.org > > > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > > > Hi Tiru, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 =C0=A0: BOUCADAIR Moham= ed > > IMT/OLN; > > > > dots@ietf.org Objet=A0: RE: [Dots] I-D > > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > > > I don't think the DOTS signal channel draft should enhance the > > > > functionality of DOTS gateway to aggregate mitigation requests, it'= s > > > > not discussed in any of the requirements and architecture drafts. > > > > > > [Med] IMO, it is out of the scope of the document to recommend or > > > preclude this. > > > > Agreed. > > > > > The main outcome of the discussion is that we don't have anymore a > > > confusion to interpret the presence of multiple client-ids. The only > > > provision is when a gateway decides to aggregate. Why and how > > > aggregation is done is really out of scope. > > > > The problem is the draft is now discussing how the DOTS gateway will > > generate multiple client-ids when aggregating mitigation requests from > > multiple DOTS clients. It's enhancing the scope of the DOTS gateway to > > handle a lot more functionality, currently not covered and discussed in > the > > requirements and architecture drafts. > > > > [Jon] As discussed elsewhere, to me aggregation of mitigation-id / > alias- > > name / filter requests is a real challenge and I can only think of a > couple of > > do-able scenarios out of a lot of different aggregation scenarios. > > I am in agreement with you Tiru that aggregation is really all about > session > > aggregation, but recognize that someone may want to attempt to do this > > aggregation of mitigation-id / alias-name / filter requests >=20 > Agreed. DOTS architecture draft should be updated to clarify the scope of > aggregation is only at session level and > remove text from the DOTS signal channel draft discussing aggregation of > mitigation requests. [Med] Updating the scope in the arch draft won't solve interoperability pro= blems that may raise in the future if a gateways is designed (for its own r= easons) to aggregate requests. With the current approach in -14, the server= has a clear meaning how to interpret multiple client-ids. We don't have an= y more an ambiguity.=20 Further, a gateway designer won't "play" with multiple client-ids for other= purposes, because he/she is aware that the server has already a clear mean= ing for it. This is really good for interoperability.=20 I still don't think we have arguments to recommend nor to preclude gateways= from aggregating requests. Some complexity will be induced by such designs= , Sure. But one may argue that aggregation will solve a problem during recu= rsive signaling, or during massive attacks received on a large number of ne= tworks that are assigned with aggregable prefixes, etc. Who knows? >=20 > > [Jon] I have > > mentioned in another discussion > > NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read > (which > > may be where some of the confusion comes in) Figure 7: Client-Side > > Gateway with session Aggregation Figure 8: Client-Side Gateway without > > session Aggregation Figure 9: Server-Side Gateway with session > Aggregation > > Figure 10: Server-Side Gateway without session Aggregation > > > > > > > > > Why should the DOTS server send heartbeat request immediately after > > > > receiving the heartbeat request from the client, DOTS server anyway= s > > > > will send a heartbeat response (CoAP Reset message) for the > > > > heartbeat request from the client and that will keep the NAT bindin= g > > alive. > > > > > > [Med] The problem is not in that direction. The problem is when the > > > server sends a heartbeat request to the client but no mapping is foun= d > > > in the translator/firewall. Sending immediately the probe while the > > > NAT mapping is likely to be open will ease nat traversal. This is a > > > MAY. A serever is not obliged to follow it. > > > > Yes, I understand but it looks un-necessary on the DOTS server to > > immediately send a probe. Can you explain a scenario how the client > initiated > > heartbeat exchange is not sufficient to keep its NAT binding alive ? > > (see https://tools.ietf.org/html/rfc5245#section-10, keepalives to keep > NAT > > bindings is unidirectional only and don't invoke a response from the > peer). > > > > [Jon] If the heartbeat frequency is, say, 10 minutes (a time longer tha= n > the > > NAT session timeout), and the DOTS server and DOTS client drift in thei= r > time > > to re-transmit, you could end up with the client triggering at time +0, > > +10, +20 etc. and the server triggering at +5, +15, +25 etc. When the > > server comes to transmit its heartbeat, there is no NAT session - and > hence > > failure. If the DOTS server heartbeat transmission is synchronized to > the > > DOTS client, then there is no issue with NAT and the requirement that > both > > server and client transmit heartbeats to network test is fulfilled. >=20 > If the heartbeat frequency is higher than the NAT session timeout, the > heartbeat request packet from the DOTS client could get a different publi= c > source IP address and/or a different public source port allocated by NAT > and the packet will be rejected by the DOTS server (no corresponding DTLS > state associated with the 5-tuple). >=20 [Med] Tiru, this is a distinct problem. The initial optimization is about a= server sending a probe when it is likely that the mapping used by the pack= et sent by the DOTS client is still active. If the server waited too long, = that mapping would be removed from the table. Of course, if some validation= failed, the received probe request from the client will be rejected at the= first place and this optimization won't be followed.=20 > It is the responsibility of the DOTS client to maintain its NAT binding > and not the problem of the DOTS server. >=20 > > [Jon] There is a desire for the heartbeat rate to have long intervals i= n > peace- > > time - and sending keep-alives at a higher rate to keep NAT "warm" > > defeats this. > > > > > > > > > Why cannot the client-identifier be generated by client-side DOTS > > > > gateway (I don't understand the privacy problem, if the > > > > client-identifier does not reveal the actual DOTS client identity) = ? > > > > > > [Med] because, e.g., "DOTS server can fully trust the server-side > > > gateway but cannot fully trust the client-side gateway". > > > > Yes, but client-identifier can also be used to detect and resolve > collision (e.g. > > two DOTS clients using the same alias-name). How will collisions be > handled > > with this change ? > > > > [Jon] If we are NOT adding in defined intelligence to a DOTS gateway as > to > > how to aggregate mitigation-id/alias-name/filters etc., then the client= - > > identifiers (to me) are the only easy way to avoid collisions with the > names of > > mitigation-ids, alias-names and filters. Otherwise, the DOTS gateway > will > > need to "mangle" mitigation-id/alias-name/filters into an unique > definition > > per DOTS client before passing them on upstream. > > Actually, client-identifier + mitigation-id is an example of the mangle= d > entity... >=20 > Agreed, the text needs to reverted back to allow both client-side and > server-side gateways to add/update client-identifier. [Med] Please note that the draft allows to relax the constraint on the clie= nt-side GW: In order to prevent leaking internal information outside a client- domain, DOTS gateways located in the client-domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (client-identifier) unless explicitly configured to do so. But... When a client-side GW inserts that information, it won't be trusted by the = server domain. It will be handled as any client-id that is supplied directl= y by a client.=20 ** A server or a server-side gateway does not know if the peer DOTS agent i= s a GW or a pure DOTS client. **=20 The previous text is broken, we need to fix it. IMHO, the text has to be co= nsistent: (1) Either it should be updated to allow any client agent (including DOTS c= lients) to insert the identifier, but still it is up to the server-side may= control it. The issue I have with this approach is: what is the purpose of= inserting this identifier by a client? We need solid arguments for this.=20 (2) Either we disallow it for obvious reasons (the peer server-side agent h= as sufficient information to identify the peer client agent and enforce pol= icies accordingly). Supplying additional information won't be any way for i= dentification and authorization. =20 >=20 > Cheers, > -Tiru >=20 > > > > -Tiru > > > > > > > > A network operator can decide to deploy multiple DOTS clients and hid= e > > > the identity of these clients. To that purpose, it can enable GW in > > > its domain to hide those clients. > > > > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: Tuesday, December 19, 2017 9:05 PM > > > > > To: dots@ietf.org > > > > > Subject: Re: [Dots] I-D Action: > > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > Re-, > > > > > > > > > > This version integrates the outcomes of the mailing list > > > > > discussion, in > > > > > particular: > > > > > - Multiple client-id values does not mean anymore that multiple > > > > > GWs have injected a value each. > > > > > - Introduce attack-time-config and peace-time-config > > > > > - Add some text to suggest dots servers to send heartbeats > > > > > immediately after receiving the one from the peer dots client. > > > > > - Refreshing the configuration must not occur during attack times= . > > > > > > > > > > The document is still using client-side and server-side DOTS GW > terms. > > > > The > > > > > text will be aligned with the requirements I-D. > > > > > > > > > > Jon, please double check. > > > > > > > > > > All, please review and share your comments. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de intern= et- > > > > > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0= =A0: > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D > Action: > > > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts directories. > > > > > > This draft is a work item of the DDoS Open Threat Signaling WG > > > > > > of the IETF. > > > > > > > > > > > > Title : Distributed Denial-of-Service Open > Threat > > > > > > Signaling (DOTS) Signal Channel > > > > > > Authors : Tirumaleswar Reddy > > > > > > Mohamed Boucadair > > > > > > Prashanth Patil > > > > > > Andrew Mortensen > > > > > > Nik Teague > > > > > > Filename : draft-ietf-dots-signal-channel-14.txt > > > > > > Pages : 84 > > > > > > Date : 2017-12-19 > > > > > > > > > > > > Abstract: > > > > > > This document specifies the DOTS signal channel, a protocol > for > > > > > > signaling the need for protection against Distributed Denial= - > of- > > > > > > Service (DDoS) attacks to a server capable of enabling > network > > > > > > traffic mitigation on behalf of the requesting client. > > > > > > > > > > > > A companion document defines the DOTS data channel, a > separate > > > > > > reliable communication layer for DOTS management and > > configuration > > > > > > purposes. > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > Please update these statements with the RFC number to be > > > > > > assigned > > > > to > > > > > > this document: > > > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > Signaling > > > > > > (DOTS) Signal Channel"; > > > > > > > > > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > o This RFC > > > > > > > > > > > > Please update TBD statements with the port number to be > > > > > > assigned > > > to > > > > > > DOTS Signal Channel Protocol. > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel= / > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-ch= a > > > > > > nn > > > > > > el-1 > > > > > > 4 > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-chan= nel > > > > > > -1 > > > > > > 4 > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Dec 19 23:12:13 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6809B126DEE for ; Tue, 19 Dec 2017 23:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMb5YJPU8eez for ; Tue, 19 Dec 2017 23:12:10 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C12E126D45 for ; Tue, 19 Dec 2017 23:12:10 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id C2CBE12068A; Wed, 20 Dec 2017 08:12:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 9E287180085; Wed, 20 Dec 2017 08:12:08 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 08:12:08 +0100 From: To: "Mortensen, Andrew" , Jon Shallow CC: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzIe1SBtvp2XUqJiA0/nltgO6NKzAeAgABcPYD///QZgIAABXsAgACfLoA= Date: Wed, 20 Dec 2017 07:12:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09B2AC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <048901d3790f$6dd48170$497d8450$@jpshallow.com> <07A9F5E9-03B4-4875-8FB9-B72B8C3FFAD2@arbor.net> In-Reply-To: <07A9F5E9-03B4-4875-8FB9-B72B8C3FFAD2@arbor.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09B2ACOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 07:12:12 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09B2ACOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmV3LCBKb24sDQoNClRoaXMgd29ya3MgZm9yIG1lLCB0b28uDQoNCkNoZWVycywNCk1l ZA0KDQpEZSA6IE1vcnRlbnNlbiwgQW5kcmV3IFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRd DQpFbnZvecOpIDogbWFyZGkgMTkgZMOpY2VtYnJlIDIwMTcgMjI6NDINCsOAIDogSm9uIFNoYWxs b3cNCkNjIDogZG90czsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KT2JqZXQgOiBSZTogW0Rv dHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0xNC50eHQNCg0K DQpPbiBEZWMgMTksIDIwMTcsIGF0IDQ6MjIgUE0sIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6DQoN CkhpIEFuZHJldywNCg0KRG9lcyDigJxpZGxlLWNvbmZpZ+KAnSBhbmQg4oCcbWl0aWdhdGluZy1j b25maWfigJ0gd29yayBmb3IgeW91Pw0KDQpUaGV5IGRvLg0KDQphbmRyZXcNCg0KDQoNCg0KDQpG cm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE1vcnRlbnNlbiwgQW5kcmV3DQpTZW50OiAxOSBE ZWNlbWJlciAyMDE3IDIxOjA1DQpUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCkNjOiBkb3RzQGlldGYub3JnPG1haWx0 bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMTQudHh0DQoNClRoYW5rcywgTWVkLiBPbmUgY29tbWVu dCBhZnRlciBhIHF1aWNrIHNraW0gb2YgdGhlIHVwZGF0ZWQgZHJhZnQuDQoNCknigJltIGNvbmNl cm5lZCBhYm91dCBkZXNpZ25hdGluZyBhdHRhY2stdGltZSBhbmQgcGVhY2UtdGltZSBjb25maWcu IEEgRE9UUyBjbGllbnQgaXMgZnJlZSB0byBkZWFsIHdpdGggYSBERG9TIGF0dGFjayB3aXRob3V0 IHJlcXVlc3RpbmcgdXBzdHJlYW0gbWl0aWdhdGlvbiwgb3IgZm9yIHZhcmlvdXMgcmVhc29ucyBt YXkgd2l0aGRyYXcgYW4gYWN0aXZlIG1pdGlnYXRpb24gcmVxdWVzdCBkdXJpbmcgYW4gYXR0YWNr LiBUaGUg4oCcYXR0YWNrLXRpbWXigJ0gdGVybSB0byBtZSBpbXBsaWVzIHNvbWV0aGluZyBhbHdh eXMgdGFraW5nIHBsYWNlIHdoZW4gYW4gYXR0YWNrIGlzIGFjdGl2ZSwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIHRoZSBET1RTIGNsaWVudCBoYXMgcmVxdWVzdCBtaXRpZ2F0aW9uLiBUaGUgZGlzdGlu Y3Rpb24gd2Ugd2FudCB0byBkcmF3IGlzIHJlYWxseSBiZXR3ZWVuIGEgY29uZmlnIGVuYWJsZWQg d2hlbiBtaXRpZ2F0aW9uIGlzIHJlcXVlc3RlZC9hY3RpdmUsIGFuZCB3aGVuIHRoZSBjbGllbnQg aGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdhdGlvbi4NCg0KSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUg YmVzdCB0ZXJtaW5vbG9neSBpcyBmb3IgdGhpcyBkaXN0aW5jdGlvbi4gU29tZXRoaW5nIGxpa2Ug 4oCcaWRsZS1jb25maWfigJ0gYW5kIOKAnG1pdGlnYXRpb24tY29uZmln4oCdIGdldCBjbG9zZXIg dG8gdGhlIHNwaXJpdCBvZiB3aGF0IEkgdGhpbmsgd2Ugd2FudCwgdGhvdWdoLg0KDQphbmRyZXcN Cg0KDQpPbiBEZWMgMTksIDIwMTcsIGF0IDEwOjM0IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KUmUt LA0KDQpUaGlzIHZlcnNpb24gaW50ZWdyYXRlcyB0aGUgb3V0Y29tZXMgb2YgdGhlIG1haWxpbmcg bGlzdCBkaXNjdXNzaW9uLCBpbiBwYXJ0aWN1bGFyOg0KLSBNdWx0aXBsZSBjbGllbnQtaWQgdmFs dWVzIGRvZXMgbm90IG1lYW4gYW55bW9yZSB0aGF0IG11bHRpcGxlIEdXcyBoYXZlIGluamVjdGVk IGEgdmFsdWUgZWFjaC4NCi0gSW50cm9kdWNlIGF0dGFjay10aW1lLWNvbmZpZyBhbmQgcGVhY2Ut dGltZS1jb25maWcNCi0gQWRkIHNvbWUgdGV4dCB0byBzdWdnZXN0IGRvdHMgc2VydmVycyB0byBz ZW5kIGhlYXJ0YmVhdHMgaW1tZWRpYXRlbHkgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBvbmUgZnJvbSB0 aGUgcGVlciBkb3RzIGNsaWVudC4NCi0gUmVmcmVzaGluZyB0aGUgY29uZmlndXJhdGlvbiBtdXN0 IG5vdCBvY2N1ciBkdXJpbmcgYXR0YWNrIHRpbWVzLg0KDQpUaGUgZG9jdW1lbnQgaXMgc3RpbGwg dXNpbmcgY2xpZW50LXNpZGUgYW5kIHNlcnZlci1zaWRlIERPVFMgR1cgdGVybXMuIFRoZSB0ZXh0 IHdpbGwgYmUgYWxpZ25lZCB3aXRoIHRoZSByZXF1aXJlbWVudHMgSS1ELg0KDQpKb24sIHBsZWFz ZSBkb3VibGUgY2hlY2suDQoNCkFsbCwgcGxlYXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21t ZW50cy4NCg0K --_000_787AE7BB302AE849A7480A190F8B93300A09B2ACOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNw YW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBi dWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ SGkgQW5kcmV3LCBKb24sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgd29ya3MgZm9y IG1lLCB0b28uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBNb3J0ZW5zZW4sIEFuZHJldyBbbWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0 XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDE5IGTDqWNlbWJyZSAyMDE3IDIy OjQyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBKb24gU2hhbGxvdzxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gZG90czsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPk9iamV0Jm5ic3A7Ojwv Yj4gUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwt MTQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRGVjIDE5LCAyMDE3LCBhdCA0OjIyIFBNLCBKb24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmRyZXcs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Eb2VzIOKAnGlkbGUtY29u Zmln4oCdIGFuZCDigJxtaXRpZ2F0aW5nLWNvbmZpZ+KAnSB3b3JrIGZvciB5b3U/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXkgZG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZHJldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRvdHMNCiBbbWFpbHRvOiA8YSBo cmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5P biBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9iPk1vcnRlbnNlbiwgQW5kcmV3PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjE5IERlY2VtYmVyIDIwMTcgMjE6MDU8 YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNA aWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbRG90c10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTE0LnR4dDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsIE1lZC4gT25lIGNvbW1lbnQgYWZ0ZXIgYSBxdWljayBza2ltIG9mIHRoZSB1cGRh dGVkIGRyYWZ0LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGNvbmNlcm5lZCBhYm91dCBkZXNpZ25hdGluZyBh dHRhY2stdGltZSBhbmQgcGVhY2UtdGltZSBjb25maWcuIEEgRE9UUyBjbGllbnQgaXMgZnJlZSB0 byBkZWFsIHdpdGggYSBERG9TIGF0dGFjayB3aXRob3V0IHJlcXVlc3RpbmcgdXBzdHJlYW0gbWl0 aWdhdGlvbiwgb3IgZm9yIHZhcmlvdXMgcmVhc29ucyBtYXkgd2l0aGRyYXcgYW4gYWN0aXZlIG1p dGlnYXRpb24gcmVxdWVzdCBkdXJpbmcgYW4gYXR0YWNrLg0KIFRoZSDigJxhdHRhY2stdGltZeKA nSB0ZXJtIHRvIG1lIGltcGxpZXMgc29tZXRoaW5nIGFsd2F5cyB0YWtpbmcgcGxhY2Ugd2hlbiBh biBhdHRhY2sgaXMgYWN0aXZlLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIERPVFMgY2xpZW50 IGhhcyByZXF1ZXN0IG1pdGlnYXRpb24uIFRoZSBkaXN0aW5jdGlvbiB3ZSB3YW50IHRvIGRyYXcg aXMgcmVhbGx5IGJldHdlZW4gYSBjb25maWcgZW5hYmxlZCB3aGVuIG1pdGlnYXRpb24gaXMgcmVx dWVzdGVkL2FjdGl2ZSwNCiBhbmQgd2hlbiB0aGUgY2xpZW50IGhhcyBub3QgcmVxdWVzdGVkIG1p dGlnYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBzdXJlIHdoYXQg dGhlIGJlc3QgdGVybWlub2xvZ3kgaXMgZm9yIHRoaXMgZGlzdGluY3Rpb24uIFNvbWV0aGluZyBs aWtlIOKAnGlkbGUtY29uZmln4oCdIGFuZCDigJxtaXRpZ2F0aW9uLWNvbmZpZ+KAnSBnZXQgY2xv c2VyIHRvIHRoZSBzcGlyaXQgb2Ygd2hhdCBJIHRoaW5rIHdlIHdhbnQsIHRob3VnaC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kcmV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBEZWMgMTksIDIwMTcsIGF0IDEwOjM0IEFNLDxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5SZS0sPGJyPg0KPGJyPg0KVGhpcyB2ZXJzaW9uIGludGVncmF0ZXMgdGhlIG91 dGNvbWVzIG9mIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiwgaW4gcGFydGljdWxhcjo8YnI+ DQotIE11bHRpcGxlIGNsaWVudC1pZCB2YWx1ZXMgZG9lcyBub3QgbWVhbiBhbnltb3JlIHRoYXQg bXVsdGlwbGUgR1dzIGhhdmUgaW5qZWN0ZWQgYSB2YWx1ZSBlYWNoLjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQotIEludHJvZHVjZSBhdHRhY2st dGltZS1jb25maWcgYW5kIHBlYWNlLXRpbWUtY29uZmlnPGJyPg0KLSBBZGQgc29tZSB0ZXh0IHRv IHN1Z2dlc3QgZG90cyBzZXJ2ZXJzIHRvIHNlbmQgaGVhcnRiZWF0cyBpbW1lZGlhdGVseSBhZnRl ciByZWNlaXZpbmcgdGhlIG9uZSBmcm9tIHRoZSBwZWVyIGRvdHMgY2xpZW50LjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQotIFJlZnJlc2hpbmcg dGhlIGNvbmZpZ3VyYXRpb24gbXVzdCBub3Qgb2NjdXIgZHVyaW5nIGF0dGFjayB0aW1lcy48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQpUaGUgZG9jdW1lbnQgaXMgc3RpbGwgdXNpbmcgY2xpZW50LXNpZGUgYW5kIHNlcnZlci1zaWRl IERPVFMgR1cgdGVybXMuIFRoZSB0ZXh0IHdpbGwgYmUgYWxpZ25lZCB3aXRoIHRoZSByZXF1aXJl bWVudHMgSS1ELjxicj4NCjxicj4NCkpvbiwgcGxlYXNlIGRvdWJsZSBjaGVjay48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KQWxsLCBw bGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300A09B2ACOPEXCLILMA3corp_-- From nobody Tue Dec 19 23:28:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D7B124207 for ; Tue, 19 Dec 2017 23:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKH9tdlHjCvL for ; Tue, 19 Dec 2017 23:28:40 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DC0120721 for ; Tue, 19 Dec 2017 23:28:39 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 85BCC60CED; Wed, 20 Dec 2017 08:28:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 6C4198006F; Wed, 20 Dec 2017 08:28:38 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 08:28:38 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQgAD7FCA= Date: Wed, 20 Dec 2017 07:28:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09B2C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 07:28:42 -0000 Tiru,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: mardi 19 d=E9cembre 2017 17:51 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, December 19, 2017 9:44 PM > > To: Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > Hi Tiru, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots]= I-D > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > I don't think the DOTS signal channel draft should enhance the > > > functionality of DOTS gateway to aggregate mitigation requests, it's > > > not discussed in any of the requirements and architecture drafts. > > > > [Med] IMO, it is out of the scope of the document to recommend or > > preclude this. >=20 > Agreed. >=20 > > > Why cannot the client-identifier be generated by client-side DOTS > > > gateway (I don't understand the privacy problem, if the > > > client-identifier does not reveal the actual DOTS client identity) ? > > > > [Med] because, e.g., "DOTS server can fully trust the server-side > gateway > > but cannot fully trust the client-side gateway". >=20 > Yes, but client-identifier can also be used to detect and resolve > collision (e.g. two DOTS clients using the same alias-name). How will > collisions be handled with this change ? >=20 [Med] The question is whether we need to handle this as a bug or feature: e= .g.,=20 * DOTS clients, which belong to the same domain, using the same alias can b= e handled as part of conflict management and be reported by the final serve= r as such. * The client-side DOTS gateway may be instructed to detect locally collisio= n/conflicts and notify the responsible clients locally. Collisions are not = leaked to the server domain. =20 From nobody Wed Dec 20 01:07:33 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A212D960 for ; Wed, 20 Dec 2017 01:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqBH9km0UAOa for ; Wed, 20 Dec 2017 01:07:29 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AF612D864 for ; Wed, 20 Dec 2017 01:07:29 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513760848; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=spCpxQxyLFbwACWqjc4iZNVCBqsPI6DQPwy/SS UdcFI=; b=MbO8Hgi7H7VR3OjvsBWkrjv3DdnvOaaeKrtzERYG p4/kuMTzOn/MakrOVKOmiPCxpo2zuzFOWenpBfmOndC3/QHCY0 PDMxDy9ko8FclYFF6ajJyGETGtYiC+/pkoAeDUIy70ebtuaLv9 T0LiPEXDV9Krp+sT6nX1Y07N/GT4N50= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 39a6_c107_02eb5c28_1c59_42f4_8f7d_1b05cf416e08; Wed, 20 Dec 2017 03:07:28 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 02:06:45 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 02:06:44 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 20 Dec 2017 02:06:44 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 02:06:43 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Wed, 20 Dec 2017 09:06:43 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Wed, 20 Dec 2017 09:06:43 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQgAD7FCCAABWNgA== Date: Wed, 20 Dec 2017 09:06:42 +0000 Message-ID: References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09B2C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09B2C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:HxeEQ0ciJQ+WG3/aHuCjJxtk0oTKID8qdWw9rRzoId80hl1lIK0h/8aXn0Utn8be7hN75S4mLjOX0/ZKSHJY/cNu9VK+QP+pXt8nAZtDYIDZBkOP4dc32aR2N8g7R2KQvUC6W+wQVw26Y3zf4cXXE+yTM65xDBjAyIsQ2LVKbBUC5zpz5GfTRv2KggsT6+nDTjBrs+Bi3Zfpnr/FdK3/3SH5NCTAtFE83/ZpORPDi1WYui5JgN12HX9z0T9XFcOESghSfRPksPvhCvqqPu2JFQcCIgg8cyi42vct5mF9LRu2FSTLE/iBr+u5SJ5rjTFM3McoOwwixYbGjv2F1nvLYBd9EV6nLPqGDYbtWcLUk0o=; 5:jej8COD69jH1LVPkdZ/4luaMzczQnC0pFIFPD8MkV9ekQTc7Y1MB2PWzmmMdCUtv2os9UthKgIB3FBBzWlRFm1xZJ+Gr7iazmmmI1uz4WcR+X/KGB9CrEZNZUoNh40Z2/UxSKSY9B96YJjxE7jT/twqE9rBaSrJCxak58pdCPng=; 24:7C78myvI/IVBQyRmzK4dqHK+QwaG+Ziw/Aind07Nl/dcRcaMJJ66v/cWAO29Vysnf2zhkhoCac7sM4YDIbZ0sIQvCaDkK55xz9527tn6Uiw=; 7:FgbJbVvAFw+9Pd6rzmewcRM5MQVvc8vRTiIjEWevyDzjT/7EuSlGTp+Q/izPqVpEKWtmQqjUFpVOuThcHrOJVe9khONOd/thHoKxJM9G0S0jJr6m9fkx/p7WV7P+JyNNkTSpO5OE5KPlyTEVJpJkQ95Yb+EbCYT3L9z7GVLVcQIGwZU2J9OdFe3Ke6V7zdgFddn+dVassOJXNcHf+PWxJQ4vL5b+ght1D8KIOGpELg8Ocqs9s+QCL+f1lFXzvCyl x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 683aa144-1c23-4d5f-d48c-08d54788fd3a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(10201501046)(93006095)(93001095)(3002001)(6041268)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(346002)(366004)(376002)(396003)(32952001)(13464003)(199004)(189003)(55784002)(25786009)(7696005)(6116002)(76176011)(102836003)(230783001)(3846002)(2950100002)(86362001)(99286004)(93886005)(966005)(478600001)(33656002)(72206003)(105586002)(14454004)(59450400001)(97736004)(66066001)(80792005)(77096006)(81166006)(81156014)(8676002)(8936002)(229853002)(2900100001)(305945005)(7736002)(74316002)(106356001)(2501003)(53936002)(316002)(3660700001)(5660300001)(6246003)(2906002)(110136005)(3280700002)(6306002)(55016002)(9686003)(6506007)(53546011)(68736007)(6436002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 683aa144-1c23-4d5f-d48c-08d54788fd3a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 09:06:43.0221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6183> : inlines <6270> : streams <1773646> : uri <2554282> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:07:32 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, December 20, 2017 12:59 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Tiru, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 17:51 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] I= -D > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Tuesday, December 19, 2017 9:44 PM > > > To: Konda, Tirumaleswar Reddy > > > ; dots@ietf.org > > > Subject: RE: [Dots] I-D Action: > > > draft-ietf-dots-signal-channel-14.txt > > > > > > Hi Tiru, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 =C0=A0: BOUCADAIR Moham= ed > > > > IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] I-D > > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > > > I don't think the DOTS signal channel draft should enhance the > > > > functionality of DOTS gateway to aggregate mitigation requests, > > > > it's not discussed in any of the requirements and architecture draf= ts. > > > > > > [Med] IMO, it is out of the scope of the document to recommend or > > > preclude this. > > > > Agreed. > > > > > > Why cannot the client-identifier be generated by client-side DOTS > > > > gateway (I don't understand the privacy problem, if the > > > > client-identifier does not reveal the actual DOTS client identity) = ? > > > > > > [Med] because, e.g., "DOTS server can fully trust the server-side > > gateway > > > but cannot fully trust the client-side gateway". > > > > Yes, but client-identifier can also be used to detect and resolve > > collision (e.g. two DOTS clients using the same alias-name). How will > > collisions be handled with this change ? > > >=20 > [Med] The question is whether we need to handle this as a bug or feature: > e.g., > * DOTS clients, which belong to the same domain, using the same alias can= be > handled as part of conflict management and be reported by the final serve= r > as such. > * The client-side DOTS gateway may be instructed to detect locally > collision/conflicts and notify the responsible clients locally. Collision= s are not > leaked to the server domain. Please look into 3.1.8 and 3.2.2 in dots use cases spec, there could be hun= dreds of DOTS clients and it does not look like a good approach to keep rej= ecting requests just because they had the same alias-name. We discussed thi= s problem in the mailing list before agreeing to use the client-identifier = as a list to resolve collisions (see https://mailarchive.ietf.org/arch/msg/= dots/qqJ_aV8zDuwCP84qtJEmP-oIRKA).=20 -Tiru From nobody Wed Dec 20 01:10:47 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725E512D960 for ; Wed, 20 Dec 2017 01:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyVxj2emXSVZ for ; Wed, 20 Dec 2017 01:10:42 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F89B12D864 for ; Wed, 20 Dec 2017 01:10:41 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513761031; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=VqansqafQ2s4GndctOiiVFJbekssaKEEDcSpUP YnWXs=; b=QPTVk5umH7zaT79oLPblscbyMwOfPtfcGx3eAbLT iH8vYuke3noOJ2e2pRXUoeTES8bXMIJiU1NzyVXK3WErcs0aEb V5IlBbV7GcM7tX2GBxhiSrQ94nJ35+ArEF9S+tDZGKlvsaL0qV vMp4w5CcTqOCYtx/R4k52osAlfUG8wg= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 0599_a4a3_0867e5b6_0a62_4235_ac47_2da01dce3b28; Wed, 20 Dec 2017 03:10:31 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 04:10:27 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 20 Dec 2017 04:10:27 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 04:10:26 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Wed, 20 Dec 2017 09:10:25 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Wed, 20 Dec 2017 09:10:25 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQgAAT5QCAAJ3ZgIAASGuAgAAO39A= Date: Wed, 20 Dec 2017 09:10:25 +0000 Message-ID: References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <044d01d378ee$90941610$b1bc4230$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09B298@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09B298@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:luYiTZHXO/izedy8VwqouAuxmGMpXMk8EUPm001K3xnTovO4APKmSvtflYH9zspCt9/U0HBqbrcP0GCiuc6ovFrJL7KZxjln/5KQk5gBrzZN1sZUbPk5pXujJvppve68hrxe6d6esyI6MU5n4FFyKTBgqeoRoEfbXgbVcBOLly+wA9yixkj+8400U1yF0d1mKymYNpcVPSyE+6GgQRkc7sBEYh12hvon+YkcxtnWffu2LfJ+u75B+BYQVCbIw4PpOKazKnsMGJjTn41epaVZMhnicFRET5WQbajaGjgs97njDkBRAZ/miy0hRZJTZ7zUIpXRQNh2HNzRZcoZZB7Y7eHD+ewAWyxJ2M/71x59Chc=; 5:1twPykwe7gAApVzQKKNRD0hjYI74cBHivflAFSG5ybvDhvIYnOQQ2aXMg53/af8PaJLyoYbVEubqDWTfo6tZ+LGwr96IL838/vIu2gVv3kFKzBapCjZPaa+hOy7il4yi1/E4jKJplLV+baFDeOW5AzIQzIfp1Dw9JezpLSn+XoQ=; 24:VJoFhb2GlAX0NeNsru54Iv/ugWNJSxhYbPDBQLNB1HX5KFWz7LuPr2DYdnkSKln3Z7F123USgbOwIgiOg1EH+RuuehPFHbl7l95tOk4FSzQ=; 7:dL7qN115sxL4Xj93+IkGOoqAk0TMNdO5+23Z6b8Zlqfz+4TWrlQzbxgSo81mZrfTcvgcIq9kylfHS94L9U7WeU/nzKx7idp0xMPGyqlwm0746yQ31Xg7EFESvGVlDcQjiZy9FIDa+GaTS+SRIjgtlR9zvcBMRLB3bIhq7irdbA5Dy+F2DtPrMIMkFdC0xZBewruUjbW1ru5j+w7OxA7pd3Dy/9paHckO1zAGHnYEFXf8jft1t2nRdH03CcZOf590 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e9001a3c-9c05-470d-9267-08d5478981ea x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(10201501046)(93006095)(93001095)(3002001)(6041268)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(346002)(366004)(376002)(396003)(32952001)(13464003)(199004)(377424004)(189003)(55784002)(25786009)(7696005)(6116002)(76176011)(102836003)(230783001)(3846002)(2950100002)(86362001)(99286004)(93886005)(966005)(478600001)(33656002)(72206003)(105586002)(14454004)(59450400001)(97736004)(66066001)(80792005)(77096006)(81166006)(81156014)(8676002)(8936002)(229853002)(2900100001)(305945005)(7736002)(74316002)(106356001)(2501003)(53936002)(316002)(3660700001)(5660300001)(6246003)(2906002)(110136005)(3280700002)(6306002)(55016002)(9686003)(6506007)(53546011)(68736007)(4001150100001)(6436002)(53946003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9001a3c-9c05-470d-9267-08d5478981ea X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 09:10:25.6643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6183> : inlines <6270> : streams <1773646> : uri <2554282> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:10:45 -0000 Hi Med, Please see inline > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, December 20, 2017 12:41 PM > To: Konda, Tirumaleswar Reddy > ; Jon Shallow ietf@jpshallow.com>; dots@ietf.org > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Tiru, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 04:24 =C0=A0: Jon Shallow; BOU= CADAIR > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] I-D Action: > > draft-ietf-dots-signal-channel-14.txt > > > > Hi Jon, > > > > Please see inline > > > > > -----Original Message----- > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Sent: Tuesday, December 19, 2017 10:57 PM > > > To: Konda, Tirumaleswar Reddy > > > ; > > > mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: RE: [Dots] I-D Action: > > > draft-ietf-dots-signal-channel-14.txt > > > > > > Hi Tiru / Med, > > > > > > See inline [Jon]. > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > Tirumaleswar Reddy > > > Sent: 19 December 2017 16:51 > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] I-D Action: > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Tuesday, December 19, 2017 9:44 PM > > > > To: Konda, Tirumaleswar Reddy > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] I-D Action: > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > Hi Tiru, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 =C0=A0: BOUCADAIR Moh= amed > > > IMT/OLN; > > > > > dots@ietf.org Objet=A0: RE: [Dots] I-D > > > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > I don't think the DOTS signal channel draft should enhance the > > > > > functionality of DOTS gateway to aggregate mitigation requests, > > > > > it's not discussed in any of the requirements and architecture dr= afts. > > > > > > > > [Med] IMO, it is out of the scope of the document to recommend or > > > > preclude this. > > > > > > Agreed. > > > > > > > The main outcome of the discussion is that we don't have anymore a > > > > confusion to interpret the presence of multiple client-ids. The > > > > only provision is when a gateway decides to aggregate. Why and how > > > > aggregation is done is really out of scope. > > > > > > The problem is the draft is now discussing how the DOTS gateway will > > > generate multiple client-ids when aggregating mitigation requests > > > from multiple DOTS clients. It's enhancing the scope of the DOTS > > > gateway to handle a lot more functionality, currently not covered > > > and discussed in > > the > > > requirements and architecture drafts. > > > > > > [Jon] As discussed elsewhere, to me aggregation of mitigation-id / > > alias- > > > name / filter requests is a real challenge and I can only think of a > > couple of > > > do-able scenarios out of a lot of different aggregation scenarios. > > > I am in agreement with you Tiru that aggregation is really all about > > session > > > aggregation, but recognize that someone may want to attempt to do > > > this aggregation of mitigation-id / alias-name / filter requests > > > > Agreed. DOTS architecture draft should be updated to clarify the scope > > of aggregation is only at session level and remove text from the DOTS > > signal channel draft discussing aggregation of mitigation requests. >=20 > [Med] Updating the scope in the arch draft won't solve interoperability > problems that may raise in the future if a gateways is designed (for its = own > reasons) to aggregate requests. With the current approach in -14, the ser= ver > has a clear meaning how to interpret multiple client-ids. We don't have a= ny > more an ambiguity. No, multiple client-ids is also required to handle collisions.=20 >=20 > Further, a gateway designer won't "play" with multiple client-ids for oth= er > purposes, because he/she is aware that the server has already a clear > meaning for it. This is really good for interoperability. >=20 > I still don't think we have arguments to recommend nor to preclude > gateways from aggregating requests. Some complexity will be induced by > such designs, Sure. But one may argue that aggregation will solve a probl= em > during recursive signaling, or during massive attacks received on a large > number of networks that are assigned with aggregable prefixes, etc. Who > knows? If future specifications decide to aggregate mitigation requests, the DOTS = gateway can indicate that the mitigation request is aggregated, it can conv= ey a new parameter to convey the same to the upstream DOTS servers.=20 No need for the draft to discuss a undefined behavior of the DOTS gateway.= =20 >=20 > > > > > [Jon] I have > > > mentioned in another discussion > > > NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really > > > read > > (which > > > may be where some of the confusion comes in) Figure 7: Client-Side > > > Gateway with session Aggregation Figure 8: Client-Side Gateway > > > without session Aggregation Figure 9: Server-Side Gateway with > > > session > > Aggregation > > > Figure 10: Server-Side Gateway without session Aggregation > > > > > > > > > > > > Why should the DOTS server send heartbeat request immediately > > > > > after receiving the heartbeat request from the client, DOTS > > > > > server anyways will send a heartbeat response (CoAP Reset > > > > > message) for the heartbeat request from the client and that will > > > > > keep the NAT binding > > > alive. > > > > > > > > [Med] The problem is not in that direction. The problem is when > > > > the server sends a heartbeat request to the client but no mapping > > > > is found in the translator/firewall. Sending immediately the probe > > > > while the NAT mapping is likely to be open will ease nat > > > > traversal. This is a MAY. A serever is not obliged to follow it. > > > > > > Yes, I understand but it looks un-necessary on the DOTS server to > > > immediately send a probe. Can you explain a scenario how the client > > initiated > > > heartbeat exchange is not sufficient to keep its NAT binding alive ? > > > (see https://tools.ietf.org/html/rfc5245#section-10, keepalives to > > > keep > > NAT > > > bindings is unidirectional only and don't invoke a response from the > > peer). > > > > > > [Jon] If the heartbeat frequency is, say, 10 minutes (a time longer > > > than > > the > > > NAT session timeout), and the DOTS server and DOTS client drift in > > > their > > time > > > to re-transmit, you could end up with the client triggering at time > > > +0, > > > +10, +20 etc. and the server triggering at +5, +15, +25 etc. When > > > +the > > > server comes to transmit its heartbeat, there is no NAT session - > > > and > > hence > > > failure. If the DOTS server heartbeat transmission is synchronized > > > to > > the > > > DOTS client, then there is no issue with NAT and the requirement > > > that > > both > > > server and client transmit heartbeats to network test is fulfilled. > > > > If the heartbeat frequency is higher than the NAT session timeout, the > > heartbeat request packet from the DOTS client could get a different > > public source IP address and/or a different public source port > > allocated by NAT and the packet will be rejected by the DOTS server > > (no corresponding DTLS state associated with the 5-tuple). > > >=20 > [Med] Tiru, this is a distinct problem. The initial optimization is about= a server > sending a probe when it is likely that the mapping used by the packet sen= t by > the DOTS client is still active.=20 The server is already sending a heartbeat response (RST message) in respons= e to a heartbeat request from the DOTS client. Protocols like ICE used by = browsers for WebRTC, send STUN Binding Indication to keep NAT the binding a= live and that are send-and-forget, and do not evoke a response (see https:/= /tools.ietf.org/html/rfc5245#section-10).=20 > If the server waited too long, that mapping > would be removed from the table. Of course, if some validation failed, th= e > received probe request from the client will be rejected at the first plac= e and > this optimization won't be followed. >=20 > > It is the responsibility of the DOTS client to maintain its NAT > > binding and not the problem of the DOTS server. > > > > > [Jon] There is a desire for the heartbeat rate to have long > > > intervals in > > peace- > > > time - and sending keep-alives at a higher rate to keep NAT "warm" > > > defeats this. > > > > > > > > > > > > Why cannot the client-identifier be generated by client-side > > > > > DOTS gateway (I don't understand the privacy problem, if the > > > > > client-identifier does not reveal the actual DOTS client identity= ) ? > > > > > > > > [Med] because, e.g., "DOTS server can fully trust the server-side > > > > gateway but cannot fully trust the client-side gateway". > > > > > > Yes, but client-identifier can also be used to detect and resolve > > collision (e.g. > > > two DOTS clients using the same alias-name). How will collisions be > > handled > > > with this change ? > > > > > > [Jon] If we are NOT adding in defined intelligence to a DOTS gateway > > > as > > to > > > how to aggregate mitigation-id/alias-name/filters etc., then the > > > client- identifiers (to me) are the only easy way to avoid > > > collisions with the > > names of > > > mitigation-ids, alias-names and filters. Otherwise, the DOTS > > > gateway > > will > > > need to "mangle" mitigation-id/alias-name/filters into an unique > > definition > > > per DOTS client before passing them on upstream. > > > Actually, client-identifier + mitigation-id is an example of the > > > mangled > > entity... > > > > Agreed, the text needs to reverted back to allow both client-side and > > server-side gateways to add/update client-identifier. >=20 > [Med] Please note that the draft allows to relax the constraint on the cl= ient- > side GW: >=20 > In order to prevent leaking internal information outside a client- > domain, DOTS gateways located in the client-domain SHOULD NOT reveal > the identification information that pertains to internal DOTS clients > (client-identifier) unless explicitly configured to do so. >=20 > But... >=20 > When a client-side GW inserts that information, it won't be trusted by th= e > server domain. It will be handled as any client-id that is supplied direc= tly by a > client. Client-identifier list is only required to uniquely identify the request (e= .g. alias-name) and not for any other purpose but the 'client-identifier' v= alue to the end of the 'client-identifier' list inserted by the server-side= DOTS-gateway can be trusted by the DOTS server for policy enforcement.=20 >=20 > ** A server or a server-side gateway does not know if the peer DOTS agent= is > a GW or a pure DOTS client. ** In certain cases the server-side gateway may know if the peer DOTS agent is= a GW (e.g. recursive signaling, MSSP as an end-customer requesting overflo= w DDoS mitigation assistance from other MSSPs).=20 -Tiru >=20 > The previous text is broken, we need to fix it. IMHO, the text has to be > consistent: >=20 > (1) Either it should be updated to allow any client agent (including DOTS > clients) to insert the identifier, but still it is up to the server-side = may control > it. The issue I have with this approach is: what is the purpose of insert= ing this > identifier by a client? We need solid arguments for this. >=20 > (2) Either we disallow it for obvious reasons (the peer server-side agent= has > sufficient information to identify the peer client agent and enforce poli= cies > accordingly). Supplying additional information won't be any way for > identification and authorization. >=20 > > > > Cheers, > > -Tiru > > > > > > > > -Tiru > > > > > > > > > > > A network operator can decide to deploy multiple DOTS clients and > > > > hide the identity of these clients. To that purpose, it can enable > > > > GW in its domain to hide those clients. > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: Tuesday, December 19, 2017 9:05 PM > > > > > > To: dots@ietf.org > > > > > > Subject: Re: [Dots] I-D Action: > > > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > > > Re-, > > > > > > > > > > > > This version integrates the outcomes of the mailing list > > > > > > discussion, in > > > > > > particular: > > > > > > - Multiple client-id values does not mean anymore that > > > > > > multiple GWs have injected a value each. > > > > > > - Introduce attack-time-config and peace-time-config > > > > > > - Add some text to suggest dots servers to send heartbeats > > > > > > immediately after receiving the one from the peer dots client. > > > > > > - Refreshing the configuration must not occur during attack tim= es. > > > > > > > > > > > > The document is still using client-side and server-side DOTS > > > > > > GW > > terms. > > > > > The > > > > > > text will be aligned with the requirements I-D. > > > > > > > > > > > > Jon, please double check. > > > > > > > > > > > > All, please review and share your comments. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > > internet- drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 20= 17 16:19 > =C0=A0: > > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I= -D > > Action: > > > > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > Internet-Drafts directories. > > > > > > > This draft is a work item of the DDoS Open Threat Signaling > > > > > > > WG of the IETF. > > > > > > > > > > > > > > Title : Distributed Denial-of-Service Open > > Threat > > > > > > > Signaling (DOTS) Signal Channel > > > > > > > Authors : Tirumaleswar Reddy > > > > > > > Mohamed Boucadair > > > > > > > Prashanth Patil > > > > > > > Andrew Mortensen > > > > > > > Nik Teague > > > > > > > Filename : draft-ietf-dots-signal-channel-14.txt > > > > > > > Pages : 84 > > > > > > > Date : 2017-12-19 > > > > > > > > > > > > > > Abstract: > > > > > > > This document specifies the DOTS signal channel, a > > > > > > > protocol > > for > > > > > > > signaling the need for protection against Distributed > > > > > > > Denial- > > of- > > > > > > > Service (DDoS) attacks to a server capable of enabling > > network > > > > > > > traffic mitigation on behalf of the requesting client. > > > > > > > > > > > > > > A companion document defines the DOTS data channel, a > > separate > > > > > > > reliable communication layer for DOTS management and > > > configuration > > > > > > > purposes. > > > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > > > Please update these statements with the RFC number to be > > > > > > > assigned > > > > > to > > > > > > > this document: > > > > > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > > Signaling > > > > > > > (DOTS) Signal Channel"; > > > > > > > > > > > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > o This RFC > > > > > > > > > > > > > > Please update TBD statements with the port number to be > > > > > > > assigned > > > > to > > > > > > > DOTS Signal Channel Protocol. > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-chan > > > > > > > nel/ > > > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-1 > > > > > > > 4 > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal > > > > > > > -cha > > > > > > > nn > > > > > > > el-1 > > > > > > > 4 > > > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-ch= a > > > > > > > nnel > > > > > > > -1 > > > > > > > 4 > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 01:10:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8E312D960 for ; Wed, 20 Dec 2017 01:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRo7FWJnGElt for ; Wed, 20 Dec 2017 01:10:49 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C90B12D864 for ; Wed, 20 Dec 2017 01:10:49 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 5842120D1C for ; Wed, 20 Dec 2017 10:10:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 3C839120074 for ; Wed, 20 Dec 2017 10:10:47 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 10:10:43 +0100 From: To: "dots@ietf.org" CC: JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQHTeBYjxqCEbvGnD02xFDcIj1MzAaNL9DeA Date: Wed, 20 Dec 2017 09:10:42 +0000 Message-ID: <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:10:52 -0000 Hi all,=20 Christian has kindly reviewed this version of the draft. Many thanks to him= .=20 Proposed changes are available at: https://github.com/boucadair/IETF-Drafts= -Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-ie= tf-dots-data-channel-12.pdf=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:37 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > The main changes in this version are as follows: > - Remove target-ip because it is redundant with target-prefix > - Indicate that the order of establishing signal/data channel is > implementation/deployment specific > - Mention that the signal channel I-D is the authoritative reference for > manipulating client-id; the data channel must follow the signal channel > spec. > - Add a discussion about translation implications > - Add conflict support > - The same resource can be associated with different aliases if multiple > dots clients are deployed within a network > - Check the normative language >=20 > Please review and share comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org > > Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 > > =C0=A0: i-d-announce@ietf.org > > Cc=A0: dots@ietf.org > > Objet=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the > > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Data Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Kaname Nishizuka > > Liang Xia > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-data-channel-11.txt > > Pages : 31 > > Date : 2017-12-18 > > > > Abstract: > > The document specifies a Distributed Denial-of-Service Open Threat > > Signaling (DOTS) data channel used for bulk exchange of data not > > easily or appropriately communicated through the DOTS signal channel > > under attack conditions. > > > > This is a companion document to the DOTS signal channel > > specification. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Data Channel"; > > > > o reference: RFC XXXX > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-11 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-11 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 02:09:06 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC508126CC4 for ; Wed, 20 Dec 2017 02:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAxBKN2iUJGE for ; Wed, 20 Dec 2017 02:09:02 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE10126C0F for ; Wed, 20 Dec 2017 02:09:02 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRbJ6-0005pP-6A; Wed, 20 Dec 2017 10:09:00 +0000 From: "Jon Shallow" To: "'Jon Shallow'" , , References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> <787AE7BB302AE849A7480A190F8B93300A09AA83@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <041901d378c1$1d219e00$5764da00$@jpshallow.com> In-Reply-To: <041901d378c1$1d219e00$5764da00$@jpshallow.com> Date: Wed, 20 Dec 2017 10:09:01 -0000 Message-ID: <04f001d3797a$8eda5280$ac8ef780$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGqp9s7Rd+tZsYBc/NKbOxjivvnjAGsNuusAaVM/qWjgxa5UA== Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 10:09:05 -0000 Hi WG Thinking about this overnight, I think I prefer "Client-Side DOTS Gateway" changed to "Client-Domain DOTS gateway" "Server-Side DOTS Gateway" changed to "Server-Domain DOTS gateway" "DOTS gateway server-side" changed to "DOTS gateway server-facing-side" "DOTS gateway client-side" changed to "DOTS gateway client-facing-side" In all the appropriate documents. The reason for the latter two (taking the first one as an example) is = that "DOTS gateway server-facing-side" under the hood is the DOTS client component of the DOTS gateway. "server-side" - does it refer to the = DOTS server component side of the DOTS gateway, or is it the side of the DOTS gateway that talks to a DOTS server? Comments welcome to move forward on this one. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 19 December 2017 12:02 To: mohamed.boucadair@orange.com; rdd@cert.org; dots@ietf.org Subject: Re: [Dots] WGLC on DOTS Requirements Hi Roman and others, What triggered these term change requests was the difference in interpretation of the word "side". 'Ahh =96 the light bulb has gone off =96 why our discussions had a = disconnect. It is down to the interpretation of the word =93side=94 as used in = =93Client Side DOTS gateway=94. To you (i.e. Med) it meant =93control or ownership=94, = to me (i.e. Jon) =93connectivity or position relative to DOTS gateway=94' It actually is recorded in https://www.ietf.org/mail-archive/web/dots/current/msg01767.html=20 Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 10:16 To: Roman Danyliw; dots@ietf.org Subject: Re: [Dots] WGLC on DOTS Requirements Re-, I'm extracting this comment from Jon to be handled as part of the WGLC comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jon said:=20 To prevent others getting confused, my suggestion would be to update the following in the various draft specs "Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway" "Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway" "DOTS gateway server-side" to "DOTS gateway server-facing-side" "DOTS gateway client-side" to "DOTS gateway client-facing-side" The latter 2 should be defined somewhere. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please refer to: https://www.ietf.org/mail-archive/web/dots/current/msg01765.html. I like the initial wording, but it seems this is not clear enough and = may lead to confusion.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw = > Envoy=E9=A0: jeudi 7 d=E9cembre 2017 21:51 =C0=A0: dots@ietf.org = Objet=A0: [Dots]=20 > WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the Singapore meeting and with the=20 > concurrence of the draft authors, we are starting a working group last = > call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling=20 > Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >=20 > Please send all comments to the DOTS mailing list. >=20 > This WGLC will end on January 2, 2018 (~3 weeks to account for > end-of-the- calendar year vacations). >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 02:16:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11800126CC7 for ; Wed, 20 Dec 2017 02:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ6I3iz39xm4 for ; Wed, 20 Dec 2017 02:16:30 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF60126C0F for ; Wed, 20 Dec 2017 02:16:30 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRbQL-0005q1-6N; Wed, 20 Dec 2017 10:16:29 +0000 From: "Jon Shallow" To: , , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> In-Reply-To: <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> Date: Wed, 20 Dec 2017 10:16:30 -0000 Message-ID: <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD42im6vMQA== Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 10:16:33 -0000 Hi Med, You need to update the following in the diff pdf 1. Introduction Replace ... from these sites is protected from DDoS attacks. The DOTS client = uses the.... with ... from these sites is protected from DDoS attack mitigation. The = DOTS client uses the.... Otherwise 7.1 Install Filtering rules I-D.ietf-netmod-acl-model also supports 'reject' for actions. Should = this be added? Replace Content-Type: "application/yang+data+json" With - should not have the quotes I believe (change is needed in several places) Content-Type: application/yang+data+json Replace The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] MAY be used to specify how a ACE is inserted within an ACL and how a ACL is inserted within an ACL list. With - ACL Lists are not configured to be ordered The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] MAY be used to specify how a ACE is inserted within an ACL and how a ACL is inserted within an ACL Set in container dots-acl-order. As part of another discussion on the use of client-identifiers, I am not happy with (it is too restrictive). The draft elsewhere refers to the control of IPs being revealed In order to prevent leaking internal information outside a client- domain, client-side DOTS gateways SHOULD NOT reveal the identity of internal DOTS clients (client-identifier) unless explicitly configured to do so. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 20 December 2017 09:11 To: dots@ietf.org Cc: JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Hi all,=20 Christian has kindly reviewed this version of the draft. Many thanks to = him. Proposed changes are available at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draf= t-i etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 = 16:37 =C0=A0:=20 > dots@ietf.org Objet=A0: [Dots] TR: I-D Action:=20 > draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > The main changes in this version are as follows: > - Remove target-ip because it is redundant with target-prefix > - Indicate that the order of establishing signal/data channel is=20 > implementation/deployment specific > - Mention that the signal channel I-D is the authoritative reference=20 > for manipulating client-id; the data channel must follow the signal=20 > channel spec. > - Add a discussion about translation implications > - Add conflict support > - The same resource can be associated with different aliases if=20 > multiple dots clients are deployed within a network > - Check the normative language >=20 > Please review and share comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet-=20 > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 =C0=A0:=20 > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action:=20 > > draft-ietf-dots-data-channel-11.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of=20 > > the IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Data Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Kaname Nishizuka > > Liang Xia > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-data-channel-11.txt > > Pages : 31 > > Date : 2017-12-18 > > > > Abstract: > > The document specifies a Distributed Denial-of-Service Open = Threat > > Signaling (DOTS) data channel used for bulk exchange of data not > > easily or appropriately communicated through the DOTS signal = channel > > under attack conditions. > > > > This is a companion document to the DOTS signal channel > > specification. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned = to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Data Channel"; > > > > o reference: RFC XXXX > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-1 > > 1 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-11 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at=20 > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 03:58:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C38127871 for ; Wed, 20 Dec 2017 03:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV_jUY-8L-31 for ; Wed, 20 Dec 2017 03:58:15 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045FC1276AF for ; Wed, 20 Dec 2017 03:58:15 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 561DD60D38; Wed, 20 Dec 2017 12:58:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 3603280062; Wed, 20 Dec 2017 12:58:13 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 12:58:09 +0100 From: To: Jon Shallow , "dots@ietf.org" , JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD42im6vMQIAAEYmA Date: Wed, 20 Dec 2017 11:58:09 +0000 Message-ID: References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> In-Reply-To: <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 11:58:17 -0000 Hi Jon, Thank you for the comments.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian IMT= /OLN > Objet=A0: RE: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > You need to update the following in the diff pdf >=20 > 1. Introduction >=20 > Replace > ... from these sites is protected from DDoS attacks. The DOTS client > uses > the.... > with > ... from these sites is protected from DDoS attack mitigation. The DOTS > client uses the.... >=20 [Med] Do you really mean "protect..." from "...mitigation"? > Otherwise >=20 > 7.1 Install Filtering rules >=20 > I-D.ietf-netmod-acl-model also supports 'reject' for actions. Should thi= s > be added? >=20 > Replace > Content-Type: "application/yang+data+json" > With - should not have the quotes I believe (change is needed in several > places) > Content-Type: application/yang+data+json >=20 [Med] Good catch. Fixed. Thanks.=20 > Replace > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] > MAY be used to specify how a ACE is inserted within an ACL and how a > ACL is inserted within an ACL list. > With - ACL Lists are not configured to be ordered > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] > MAY be used to specify how a ACE is inserted within an ACL and how a > ACL is inserted within an ACL Set in container dots-acl-order. >=20 [Med] I made some minor changes to your proposal:=20 The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used to specify how an Access Control Entry (ACE) is inserted within an ACL and how an ACL is inserted within an ACL set in container dots- acl-order. > As part of another discussion on the use of client-identifiers, I am not > happy with (it is too restrictive). The draft elsewhere refers to the > control of IPs being revealed >=20 > In order to prevent leaking internal information outside a client- > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > internal DOTS clients (client-identifier) unless explicitly > configured to do so. >=20 [Med] Is it too restrictive?=20 It does set the bar where an administrator has to instruct the gateway expl= icitly about the information to be inserted/leaked.=20 This text follows the reco in: https://tools.ietf.org/html/rfc8165=20 =20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 20 December 2017 09:11 > To: dots@ietf.org > Cc: JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi all, >=20 > Christian has kindly reviewed this version of the draft. Many thanks to > him. >=20 >=20 > Proposed changes are available at: > https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/wdiff%20draft-i > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:3= 7 =C0=A0: > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > The main changes in this version are as follows: > > - Remove target-ip because it is redundant with target-prefix > > - Indicate that the order of establishing signal/data channel is > > implementation/deployment specific > > - Mention that the signal channel I-D is the authoritative reference > > for manipulating client-id; the data channel must follow the signal > > channel spec. > > - Add a discussion about translation implications > > - Add conflict support > > - The same resource can be associated with different aliases if > > multiple dots clients are deployed within a network > > - Check the normative language > > > > Please review and share comments. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 =C0=A0: > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Actio= n: > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the DDoS Open Threat Signaling WG of > > > the IETF. > > > > > > Title : Distributed Denial-of-Service Open Threat > > > Signaling (DOTS) Data Channel > > > Authors : Tirumaleswar Reddy > > > Mohamed Boucadair > > > Kaname Nishizuka > > > Liang Xia > > > Prashanth Patil > > > Andrew Mortensen > > > Nik Teague > > > Filename : draft-ietf-dots-data-channel-11.txt > > > Pages : 31 > > > Date : 2017-12-18 > > > > > > Abstract: > > > The document specifies a Distributed Denial-of-Service Open Threat > > > Signaling (DOTS) data channel used for bulk exchange of data not > > > easily or appropriately communicated through the DOTS signal > channel > > > under attack conditions. > > > > > > This is a companion document to the DOTS signal channel > > > specification. > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > Please update these statements with the RFC number to be assigned > to > > > this document: > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > > (DOTS) Data Channel"; > > > > > > o reference: RFC XXXX > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-1 > > > 1 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-11 > > > > > > > > > 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. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 04:23:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F851276AF for ; Wed, 20 Dec 2017 04:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tgNjm9UZWfN for ; Wed, 20 Dec 2017 04:23:08 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39CA12741D for ; Wed, 20 Dec 2017 04:23:08 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRdOt-0005yc-2n; Wed, 20 Dec 2017 12:23:07 +0000 From: "Jon Shallow" To: , , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> In-Reply-To: Date: Wed, 20 Dec 2017 12:23:08 -0000 Message-ID: <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstoneXBrA= Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 12:23:11 -0000 Hi Med, See inline [Jon] In addition, I think that 'set-name' and 'type' in 'acl-set' should = really be called 'acl-set-name' and 'acl-set-type' respectively in all the appropriate reference points. augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-name +--rw acl-set-type -> /ietf-acl:access-lists/acl/acl-type Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 20 December 2017 11:58 To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Hi Jon, Thank you for the comments.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR = Mohamed=20 > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: = [Dots]=20 > TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > You need to update the following in the diff pdf >=20 > 1. Introduction >=20 > Replace > ... from these sites is protected from DDoS attacks. The DOTS client = > uses the.... > with > ... from these sites is protected from DDoS attack mitigation. The=20 > DOTS client uses the.... >=20 [Med] Do you really mean "protect..." from "...mitigation"? [Jon] The context here is white-listed IPs - the whitelisted IPs should = not get mitigated, not protected from DDoS attacks. So, 'yes'. [Jon] I should have added in the rest of the line "The DOTS client uses = the DOTS data channel to convey the white-listed IP prefixes of the partner sites to its DOTS server." > Otherwise >=20 > 7.1 Install Filtering rules >=20 > I-D.ietf-netmod-acl-model also supports 'reject' for actions. Should=20 > this be added? >=20 > Replace > Content-Type: "application/yang+data+json" > With - should not have the quotes I believe (change is needed in=20 > several > places) > Content-Type: application/yang+data+json >=20 [Med] Good catch. Fixed. Thanks.=20 > Replace > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] > MAY be used to specify how a ACE is inserted within an ACL and how a > ACL is inserted within an ACL list. > With - ACL Lists are not configured to be ordered > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] > MAY be used to specify how a ACE is inserted within an ACL and how a > ACL is inserted within an ACL Set in container dots-acl-order. >=20 [Med] I made some minor changes to your proposal:=20 The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used to specify how an Access Control Entry (ACE) is inserted within an ACL and how an ACL is inserted within an ACL set in container dots- acl-order. [Jon] Works for me > As part of another discussion on the use of client-identifiers, I am=20 > not happy with (it is too restrictive). The draft elsewhere refers to = > the control of IPs being revealed >=20 > In order to prevent leaking internal information outside a client- > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > internal DOTS clients (client-identifier) unless explicitly > configured to do so. >=20 [Med] Is it too restrictive?=20 It does set the bar where an administrator has to instruct the gateway explicitly about the information to be inserted/leaked.=20 This text follows the reco in: https://tools.ietf.org/html/rfc8165 [Jon] This follows on from our other discussions about = client-identifiers - which actually do not reveal the identity of the client (there is no IP information, the unique information about the client is one way hashed = into the client-identifier). That said, the DOTS server can work out how = many clients there actually are behind the gateway and which of them are more active, but I do not see this as a real security risk. All traffic is encrypted, making it difficult for any other device to work out what is going on. Without the client-identifier (or some alternative "mangling" = of the mitigation ids to provide uniqueness) the DOTS server cannot = effectively / correctly handle the same mitigation-id when requested /used by = different DOTS clients.=20 =20 =20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 20 December 2017 09:11 > To: dots@ietf.org > Cc: JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action:=20 > draft-ietf-dots-data-channel-11.txt >=20 > Hi all, >=20 > Christian has kindly reviewed this version of the draft. Many thanks=20 > to him. >=20 >=20 > Proposed changes are available at: > https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/wdiff%20draft-i > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 = 16:37 =C0=A0: > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > The main changes in this version are as follows: > > - Remove target-ip because it is redundant with target-prefix > > - Indicate that the order of establishing signal/data channel is=20 > > implementation/deployment specific > > - Mention that the signal channel I-D is the authoritative reference = > > for manipulating client-id; the data channel must follow the signal=20 > > channel spec. > > - Add a discussion about translation implications > > - Add conflict support > > - The same resource can be associated with different aliases if=20 > > multiple dots clients are deployed within a network > > - Check the normative language > > > > Please review and share comments. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- = > > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 = =C0=A0: > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts = > > > directories. > > > This draft is a work item of the DDoS Open Threat Signaling WG of=20 > > > the IETF. > > > > > > Title : Distributed Denial-of-Service Open = Threat > > > Signaling (DOTS) Data Channel > > > Authors : Tirumaleswar Reddy > > > Mohamed Boucadair > > > Kaname Nishizuka > > > Liang Xia > > > Prashanth Patil > > > Andrew Mortensen > > > Nik Teague > > > Filename : draft-ietf-dots-data-channel-11.txt > > > Pages : 31 > > > Date : 2017-12-18 > > > > > > Abstract: > > > The document specifies a Distributed Denial-of-Service Open = Threat > > > Signaling (DOTS) data channel used for bulk exchange of data = not > > > easily or appropriately communicated through the DOTS signal > channel > > > under attack conditions. > > > > > > This is a companion document to the DOTS signal channel > > > specification. > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > Please update these statements with the RFC number to be=20 > > > assigned > to > > > this document: > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat = Signaling > > > (DOTS) Data Channel"; > > > > > > o reference: RFC XXXX > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel > > > -1 > > > 1 > > > > > > A diff from the previous version is available at: > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-11 > > > > > > > > > Please note that it may take a couple of minutes from the time of=20 > > > submission until the htmlized version and diff are available at=20 > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 04:55:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99618120725 for ; Wed, 20 Dec 2017 04:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBN732Z54YEr for ; Wed, 20 Dec 2017 04:55:54 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA01126BFD for ; Wed, 20 Dec 2017 04:55:53 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 361BE20DF9; Wed, 20 Dec 2017 13:55:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 122B71A006E; Wed, 20 Dec 2017 13:55:52 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 13:55:47 +0100 From: To: Jon Shallow , "dots@ietf.org" , JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstoneXBrCAAAhHQA== Date: Wed, 20 Dec 2017 12:55:46 +0000 Message-ID: <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> In-Reply-To: <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 12:55:56 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian IMT= /OLN > Objet=A0: RE: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > See inline [Jon] >=20 > In addition, I think that 'set-name' and 'type' in 'acl-set' should reall= y > be called 'acl-set-name' and 'acl-set-type' respectively in all the > appropriate reference points. [Med] Please note that as per YANG naming conventions, there is little valu= e in repeating names in a given hierarchy. I'm sure this will be a comment we will get from yangdocto= rs if we change the names as you suggest.=20 >=20 > augment /ietf-acl:access-lists: > +--rw dots-acl-order > +--rw acl-set* [set-name type] > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-name > +--rw acl-set-type -> /ietf-acl:access-lists/acl/acl-type >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 20 December 2017 11:58 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Jon, >=20 > Thank you for the comments. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR Mohame= d > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: [Dots= ] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > You need to update the following in the diff pdf > > > > 1. Introduction > > > > Replace > > ... from these sites is protected from DDoS attacks. The DOTS client > > uses the.... > > with > > ... from these sites is protected from DDoS attack mitigation. The > > DOTS client uses the.... > > >=20 > [Med] Do you really mean "protect..." from "...mitigation"? > [Jon] The context here is white-listed IPs - the whitelisted IPs should > not > get mitigated, not protected from DDoS attacks. So, 'yes'. > [Jon] I should have added in the rest of the line "The DOTS client uses > the > DOTS data channel to convey the white-listed IP prefixes of the > partner sites to its DOTS server." >=20 > > Otherwise > > > > 7.1 Install Filtering rules > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. Should > > this be added? > > > > Replace > > Content-Type: "application/yang+data+json" > > With - should not have the quotes I believe (change is needed in > > several > > places) > > Content-Type: application/yang+data+json > > >=20 > [Med] Good catch. Fixed. Thanks. >=20 > > Replace > > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] > > MAY be used to specify how a ACE is inserted within an ACL and how a > > ACL is inserted within an ACL list. > > With - ACL Lists are not configured to be ordered > > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] > > MAY be used to specify how a ACE is inserted within an ACL and how a > > ACL is inserted within an ACL Set in container dots-acl-order. > > >=20 > [Med] I made some minor changes to your proposal: >=20 > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used > to specify how an Access Control Entry (ACE) is inserted within an > ACL and how an ACL is inserted within an ACL set in container dots- > acl-order. > [Jon] Works for me >=20 > > As part of another discussion on the use of client-identifiers, I am > > not happy with (it is too restrictive). The draft elsewhere refers to > > the control of IPs being revealed > > > > In order to prevent leaking internal information outside a client- > > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > > internal DOTS clients (client-identifier) unless explicitly > > configured to do so. > > >=20 > [Med] Is it too restrictive? >=20 > It does set the bar where an administrator has to instruct the gateway > explicitly about the information to be inserted/leaked. >=20 > This text follows the reco in: https://tools.ietf.org/html/rfc8165 >=20 > [Jon] This follows on from our other discussions about client-identifiers > - > which actually do not reveal the identity of the client (there is no IP > information, the unique information about the client is one way hashed > into > the client-identifier). That said, the DOTS server can work out how many > clients there actually are behind the gateway and which of them are more > active, but I do not see this as a real security risk. All traffic is > encrypted, making it difficult for any other device to work out what is > going on. Without the client-identifier (or some alternative "mangling" > of > the mitigation ids to provide uniqueness) the DOTS server cannot > effectively > / correctly handle the same mitigation-id when requested /used by > different > DOTS clients. >=20 >=20 [Med] In order to keep this text (and its initial intent) aside from the cl= ient-id discussion. I suggest to make this change:=20 In order to prevent leaking internal information outside a client- domain, client-side DOTS gateways SHOULD NOT reveal the identity of internal DOTS clients (e.g., source IP address) unless explicitly configured to do so.=20 We may update based on the conclusion of the client-id discussion.=20 Hope this is OK with you.=20 Please double check at: https://github.com/boucadair/IETF-Drafts-Reviews/bl= ob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-ietf-dots-dat= a-channel-12.pdf=20 > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 09:11 > > To: dots@ietf.org > > Cc: JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Hi all, > > > > Christian has kindly reviewed this version of the draft. Many thanks > > to him. > > > > > > Proposed changes are available at: > > https://github.com/boucadair/IETF-Drafts- > > Reviews/blob/master/wdiff%20draft-i > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 16= :37 =C0=A0: > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Re-, > > > > > > The main changes in this version are as follows: > > > - Remove target-ip because it is redundant with target-prefix > > > - Indicate that the order of establishing signal/data channel is > > > implementation/deployment specific > > > - Mention that the signal channel I-D is the authoritative reference > > > for manipulating client-id; the data channel must follow the signal > > > channel spec. > > > - Add a discussion about translation implications > > > - Add conflict support > > > - The same resource can be associated with different aliases if > > > multiple dots clients are deployed within a network > > > - Check the normative language > > > > > > Please review and share comments. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 =C0=A0: > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Act= ion: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > This draft is a work item of the DDoS Open Threat Signaling WG of > > > > the IETF. > > > > > > > > Title : Distributed Denial-of-Service Open Threat > > > > Signaling (DOTS) Data Channel > > > > Authors : Tirumaleswar Reddy > > > > Mohamed Boucadair > > > > Kaname Nishizuka > > > > Liang Xia > > > > Prashanth Patil > > > > Andrew Mortensen > > > > Nik Teague > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > Pages : 31 > > > > Date : 2017-12-18 > > > > > > > > Abstract: > > > > The document specifies a Distributed Denial-of-Service Open > Threat > > > > Signaling (DOTS) data channel used for bulk exchange of data not > > > > easily or appropriately communicated through the DOTS signal > > channel > > > > under attack conditions. > > > > > > > > This is a companion document to the DOTS signal channel > > > > specification. > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > Please update these statements with the RFC number to be > > > > assigned > > to > > > > this document: > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signalin= g > > > > (DOTS) Data Channel"; > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel > > > > -1 > > > > 1 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-11 > > > > > > > > > > > > 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. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 05:09:25 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B355126BFD for ; Wed, 20 Dec 2017 05:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0Z7sOOHjcXA for ; Wed, 20 Dec 2017 05:09:21 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7302112422F for ; Wed, 20 Dec 2017 05:09:21 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id C0177180377; Wed, 20 Dec 2017 14:09:19 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 9C5E11A006D; Wed, 20 Dec 2017 14:09:19 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 14:09:18 +0100 From: To: Jon Shallow , "dots@ietf.org" , JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstoneXBrCAAAhHQIAACK6g Date: Wed, 20 Dec 2017 13:09:17 +0000 Message-ID: <7f7cfd9e-29cc-46ae-a02b-87c9cf1e32bf@OPEXCLILM31.corporate.adroot.infra.ftgroup> References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> In-Reply-To: <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:09:24 -0000 Jon, One further clarification about acl-set-* names, you may want check this PR= , currently discussed in the netmod wg: https://github.com/netmod-wg/acl-mo= del/pull/21/files: s/acl-type/type s/acl-name/name s/set-name/name=20 If accepted, we will need to update the draft as follows: OLD: +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type NEW: +--rw name -> /ietf-acl:access-lists/acl/name +--rw type -> /ietf-acl:access-lists/acl/type Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:56 > =C0=A0: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Objet=A0: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian > IMT/OLN > > Objet=A0: RE: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.tx= t > > > > Hi Med, > > > > See inline [Jon] > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' should > really > > be called 'acl-set-name' and 'acl-set-type' respectively in all the > > appropriate reference points. >=20 > [Med] Please note that as per YANG naming conventions, there is little > value in repeating names in a > given hierarchy. I'm sure this will be a comment we will get from > yangdoctors if we change the names as you suggest. >=20 > > > > augment /ietf-acl:access-lists: > > +--rw dots-acl-order > > +--rw acl-set* [set-name type] > > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-name > > +--rw acl-set-type -> /ietf-acl:access-lists/acl/acl-typ= e > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 11:58 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Jon, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR Moha= med > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: [Do= ts] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > You need to update the following in the diff pdf > > > > > > 1. Introduction > > > > > > Replace > > > ... from these sites is protected from DDoS attacks. The DOTS clien= t > > > uses the.... > > > with > > > ... from these sites is protected from DDoS attack mitigation. The > > > DOTS client uses the.... > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > [Jon] The context here is white-listed IPs - the whitelisted IPs should > > not > > get mitigated, not protected from DDoS attacks. So, 'yes'. > > [Jon] I should have added in the rest of the line "The DOTS client uses > > the > > DOTS data channel to convey the white-listed IP prefixes of the > > partner sites to its DOTS server." > > > > > Otherwise > > > > > > 7.1 Install Filtering rules > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. Should > > > this be added? > > > > > > Replace > > > Content-Type: "application/yang+data+json" > > > With - should not have the quotes I believe (change is needed in > > > several > > > places) > > > Content-Type: application/yang+data+json > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > Replace > > > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040= ] > > > MAY be used to specify how a ACE is inserted within an ACL and how = a > > > ACL is inserted within an ACL list. > > > With - ACL Lists are not configured to be ordered > > > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040= ] > > > MAY be used to specify how a ACE is inserted within an ACL and how = a > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > [Med] I made some minor changes to your proposal: > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be use= d > > to specify how an Access Control Entry (ACE) is inserted within an > > ACL and how an ACL is inserted within an ACL set in container dots- > > acl-order. > > [Jon] Works for me > > > > > As part of another discussion on the use of client-identifiers, I am > > > not happy with (it is too restrictive). The draft elsewhere refers t= o > > > the control of IPs being revealed > > > > > > In order to prevent leaking internal information outside a client- > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > > > internal DOTS clients (client-identifier) unless explicitly > > > configured to do so. > > > > > > > [Med] Is it too restrictive? > > > > It does set the bar where an administrator has to instruct the gateway > > explicitly about the information to be inserted/leaked. > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > [Jon] This follows on from our other discussions about client- > identifiers > > - > > which actually do not reveal the identity of the client (there is no IP > > information, the unique information about the client is one way hashed > > into > > the client-identifier). That said, the DOTS server can work out how > many > > clients there actually are behind the gateway and which of them are mor= e > > active, but I do not see this as a real security risk. All traffic is > > encrypted, making it difficult for any other device to work out what is > > going on. Without the client-identifier (or some alternative "mangling= " > > of > > the mitigation ids to provide uniqueness) the DOTS server cannot > > effectively > > / correctly handle the same mitigation-id when requested /used by > > different > > DOTS clients. > > > > >=20 > [Med] In order to keep this text (and its initial intent) aside from the > client-id discussion. I suggest to make this change: >=20 > In order to prevent leaking internal information outside a client- > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > internal DOTS clients (e.g., source IP address) unless explicitly > configured to do so. >=20 > We may update based on the conclusion of the client-id discussion. >=20 > Hope this is OK with you. >=20 > Please double check at: https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft- > ietf-dots-data-channel-12.pdf >=20 > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 09:11 > > > To: dots@ietf.org > > > Cc: JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi all, > > > > > > Christian has kindly reviewed this version of the draft. Many thanks > > > to him. > > > > > > > > > Proposed changes are available at: > > > https://github.com/boucadair/IETF-Drafts- > > > Reviews/blob/master/wdiff%20draft-i > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 = 16:37 > =C0=A0: > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > The main changes in this version are as follows: > > > > - Remove target-ip because it is redundant with target-prefix > > > > - Indicate that the order of establishing signal/data channel is > > > > implementation/deployment specific > > > > - Mention that the signal channel I-D is the authoritative referenc= e > > > > for manipulating client-id; the data channel must follow the signal > > > > channel spec. > > > > - Add a discussion about translation implications > > > > - Add conflict support > > > > - The same resource can be associated with different aliases if > > > > multiple dots clients are deployed within a network > > > > - Check the normative language > > > > > > > > Please review and share comments. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet= - > > > > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 =C0= =A0: > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D > Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Draft= s > > > > > directories. > > > > > This draft is a work item of the DDoS Open Threat Signaling WG of > > > > > the IETF. > > > > > > > > > > Title : Distributed Denial-of-Service Open > Threat > > > > > Signaling (DOTS) Data Channel > > > > > Authors : Tirumaleswar Reddy > > > > > Mohamed Boucadair > > > > > Kaname Nishizuka > > > > > Liang Xia > > > > > Prashanth Patil > > > > > Andrew Mortensen > > > > > Nik Teague > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > Pages : 31 > > > > > Date : 2017-12-18 > > > > > > > > > > Abstract: > > > > > The document specifies a Distributed Denial-of-Service Open > > Threat > > > > > Signaling (DOTS) data channel used for bulk exchange of data > not > > > > > easily or appropriately communicated through the DOTS signal > > > channel > > > > > under attack conditions. > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > specification. > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > Please update these statements with the RFC number to be > > > > > assigned > > > to > > > > > this document: > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > Signaling > > > > > (DOTS) Data Channel"; > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channe= l > > > > > -1 > > > > > 1 > > > > > > > > > > A diff from the previous version is available at: > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-= 11 > > > > > > > > > > > > > > > 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. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 05:09:45 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8212DA00 for ; Wed, 20 Dec 2017 05:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bafMKEaLFC3H for ; Wed, 20 Dec 2017 05:09:27 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DB012D96A for ; Wed, 20 Dec 2017 05:09:27 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRe7f-00060N-6y; Wed, 20 Dec 2017 13:09:23 +0000 From: "Jon Shallow" To: , , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> In-Reply-To: <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> Date: Wed, 20 Dec 2017 13:09:24 -0000 Message-ID: <051101d37993$c1d21380$45763a80$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyaJbcS6g Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:09:29 -0000 Hi Med, See inline [Jon1]. Regards Jon -----Original Message----- From: Dots [mailto: -bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 20 December 2017 12:56 To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR = Mohamed=20 > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: = [Dots]=20 > TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > See inline [Jon] >=20 > In addition, I think that 'set-name' and 'type' in 'acl-set' should=20 > really be called 'acl-set-name' and 'acl-set-type' respectively in all = > the appropriate reference points. [Med] Please note that as per YANG naming conventions, there is little = value in repeating names in a given hierarchy. I'm sure this will be a comment = we will get from yangdoctors if we change the names as you suggest. [Jon1] Fair enough =20 >=20 > augment /ietf-acl:access-lists: > +--rw dots-acl-order > +--rw acl-set* [set-name type] > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-name > +--rw acl-set-type -> = /ietf-acl:access-lists/acl/acl-type >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 20 December 2017 11:58 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action:=20 > draft-ietf-dots-data-channel-11.txt >=20 > Hi Jon, >=20 > Thank you for the comments. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR = Mohamed=20 > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE:=20 > > [Dots] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > You need to update the following in the diff pdf > > > > 1. Introduction > > > > Replace > > ... from these sites is protected from DDoS attacks. The DOTS=20 > > client uses the.... > > with > > ... from these sites is protected from DDoS attack mitigation. The = > > DOTS client uses the.... > > >=20 > [Med] Do you really mean "protect..." from "...mitigation"? > [Jon] The context here is white-listed IPs - the whitelisted IPs=20 > should not get mitigated, not protected from DDoS attacks. So, 'yes'. > [Jon] I should have added in the rest of the line "The DOTS client=20 > uses the DOTS data channel to convey the white-listed IP prefixes of=20 > the partner sites to its DOTS server." >=20 > > Otherwise > > > > 7.1 Install Filtering rules > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. =20 > > Should this be added? [Jon1] you have not responded to this question > > > > Replace > > Content-Type: "application/yang+data+json" > > With - should not have the quotes I believe (change is needed in=20 > > several > > places) > > Content-Type: application/yang+data+json > > >=20 > [Med] Good catch. Fixed. Thanks. >=20 > > Replace > > The "insert" query parameter discussed in Section 4.8.5 of = [RFC8040] > > MAY be used to specify how a ACE is inserted within an ACL and how = a > > ACL is inserted within an ACL list. > > With - ACL Lists are not configured to be ordered > > The "insert" query parameter discussed in Section 4.8.5 of = [RFC8040] > > MAY be used to specify how a ACE is inserted within an ACL and how = a > > ACL is inserted within an ACL Set in container dots-acl-order. > > >=20 > [Med] I made some minor changes to your proposal: >=20 > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be = used > to specify how an Access Control Entry (ACE) is inserted within an > ACL and how an ACL is inserted within an ACL set in container dots- > acl-order. > [Jon] Works for me >=20 > > As part of another discussion on the use of client-identifiers, I am = > > not happy with (it is too restrictive). The draft elsewhere refers=20 > > to the control of IPs being revealed > > > > In order to prevent leaking internal information outside a client- > > domain, client-side DOTS gateways SHOULD NOT reveal the identity = of > > internal DOTS clients (client-identifier) unless explicitly > > configured to do so. > > >=20 > [Med] Is it too restrictive? >=20 > It does set the bar where an administrator has to instruct the gateway = > explicitly about the information to be inserted/leaked. >=20 > This text follows the reco in: https://tools.ietf.org/html/rfc8165 >=20 > [Jon] This follows on from our other discussions about=20 > client-identifiers > - > which actually do not reveal the identity of the client (there is no=20 > IP information, the unique information about the client is one way=20 > hashed into the client-identifier). That said, the DOTS server can=20 > work out how many clients there actually are behind the gateway and=20 > which of them are more active, but I do not see this as a real=20 > security risk. All traffic is encrypted, making it difficult for any=20 > other device to work out what is going on. Without the=20 > client-identifier (or some alternative "mangling" > of > the mitigation ids to provide uniqueness) the DOTS server cannot=20 > effectively / correctly handle the same mitigation-id when requested=20 > /used by different DOTS clients. >=20 >=20 [Med] In order to keep this text (and its initial intent) aside from the client-id discussion. I suggest to make this change:=20 In order to prevent leaking internal information outside a client- domain, client-side DOTS gateways SHOULD NOT reveal the identity of internal DOTS clients (e.g., source IP address) unless explicitly configured to do so.=20 We may update based on the conclusion of the client-id discussion.=20 Hope this is OK with you.=20 [Jon1] Yes, this is a good initial move for me. Please double check at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draf= t-i etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf=20 [Jon1] Apart from one thing above, you have captured this email thread. > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 09:11 > > To: dots@ietf.org > > Cc: JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Hi all, > > > > Christian has kindly reviewed this version of the draft. Many thanks = > > to him. > > > > > > Proposed changes are available at: > > https://github.com/boucadair/IETF-Drafts- > > Reviews/blob/master/wdiff%20draft-i > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 = 16:37 =C0=A0: > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Re-, > > > > > > The main changes in this version are as follows: > > > - Remove target-ip because it is redundant with target-prefix > > > - Indicate that the order of establishing signal/data channel is=20 > > > implementation/deployment specific > > > - Mention that the signal channel I-D is the authoritative=20 > > > reference for manipulating client-id; the data channel must follow = > > > the signal channel spec. > > > - Add a discussion about translation implications > > > - Add conflict support > > > - The same resource can be associated with different aliases if=20 > > > multiple dots clients are deployed within a network > > > - Check the normative language > > > > > > Please review and share comments. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de = internet-=20 > > > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 = =C0=A0: > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > Internet-Drafts directories. > > > > This draft is a work item of the DDoS Open Threat Signaling WG=20 > > > > of the IETF. > > > > > > > > Title : Distributed Denial-of-Service Open = Threat > > > > Signaling (DOTS) Data Channel > > > > Authors : Tirumaleswar Reddy > > > > Mohamed Boucadair > > > > Kaname Nishizuka > > > > Liang Xia > > > > Prashanth Patil > > > > Andrew Mortensen > > > > Nik Teague > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > Pages : 31 > > > > Date : 2017-12-18 > > > > > > > > Abstract: > > > > The document specifies a Distributed Denial-of-Service Open > Threat > > > > Signaling (DOTS) data channel used for bulk exchange of data = not > > > > easily or appropriately communicated through the DOTS signal > > channel > > > > under attack conditions. > > > > > > > > This is a companion document to the DOTS signal channel > > > > specification. > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > Please update these statements with the RFC number to be=20 > > > > assigned > > to > > > > this document: > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat = Signaling > > > > (DOTS) Data Channel"; > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-chann > > > > el > > > > -1 > > > > 1 > > > > > > > > A diff from the previous version is available at: > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-1 > > > > 1 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time=20 > > > > of submission until the htmlized version and diff are available=20 > > > > at tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 05:17:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13B0126BFD for ; Wed, 20 Dec 2017 05:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7owFwu_eAxv9 for ; Wed, 20 Dec 2017 05:17:54 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56F012422F for ; Wed, 20 Dec 2017 05:17:53 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eReFs-000611-CN; Wed, 20 Dec 2017 13:17:52 +0000 From: "Jon Shallow" To: , , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <7f7cfd9e-29cc-46ae-a02b-87c9cf1e32bf@OPEXCLILM31.corporate.adroot.infra.ftgroup> In-Reply-To: <7f7cfd9e-29cc-46ae-a02b-87c9cf1e32bf@OPEXCLILM31.corporate.adroot.infra.ftgroup> Date: Wed, 20 Dec 2017 13:17:53 -0000 Message-ID: <051901d37994$f14e2f30$d3ea8d90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyQDYroWYolSvaBA= Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:17:56 -0000 Hi Med, It makes sense - I guess I was baulking at 'set-name' and 'type' and = wanted to normalize them - which they have done as 'name' and 'type'. They also are proposing changing 'rule-name' to 'name' which affects the data channel draft as well. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 20 December 2017 13:09 To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Jon, One further clarification about acl-set-* names, you may want check this = PR, currently discussed in the netmod wg: https://github.com/netmod-wg/acl-model/pull/21/files: s/acl-type/type s/acl-name/name s/set-name/name=20 If accepted, we will need to update the draft as follows: OLD: +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type NEW: +--rw name -> /ietf-acl:access-lists/acl/name +--rw type -> /ietf-acl:access-lists/acl/type Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9=A0: mercredi 20 d=E9cembre 2017 = 13:56=20 > =C0=A0: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN = Objet=A0:=20 > Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR = Mohamed=20 > > IMT/OLN; dots@ietf.org; JACQUENET Christian > IMT/OLN > > Objet=A0: RE: [Dots] TR: I-D Action:=20 > > draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > See inline [Jon] > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' should > really > > be called 'acl-set-name' and 'acl-set-type' respectively in all the=20 > > appropriate reference points. >=20 > [Med] Please note that as per YANG naming conventions, there is little = > value in repeating names in a given hierarchy. I'm sure this will be a = > comment we will get from yangdoctors if we change the names as you=20 > suggest. >=20 > > > > augment /ietf-acl:access-lists: > > +--rw dots-acl-order > > +--rw acl-set* [set-name type] > > +--rw acl-set-name -> = /ietf-acl:access-lists/acl/acl-name > > +--rw acl-set-type -> = /ietf-acl:access-lists/acl/acl-type > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 11:58 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action:=20 > > draft-ietf-dots-data-channel-11.txt > > > > Hi Jon, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR = Mohamed=20 > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE:=20 > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > You need to update the following in the diff pdf > > > > > > 1. Introduction > > > > > > Replace > > > ... from these sites is protected from DDoS attacks. The DOTS=20 > > > client uses the.... > > > with > > > ... from these sites is protected from DDoS attack mitigation.=20 > > > The DOTS client uses the.... > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > [Jon] The context here is white-listed IPs - the whitelisted IPs=20 > > should not get mitigated, not protected from DDoS attacks. So,=20 > > 'yes'. > > [Jon] I should have added in the rest of the line "The DOTS client=20 > > uses the DOTS data channel to convey the white-listed IP prefixes=20 > > of the partner sites to its DOTS server." > > > > > Otherwise > > > > > > 7.1 Install Filtering rules > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. =20 > > > Should this be added? > > > > > > Replace > > > Content-Type: "application/yang+data+json" > > > With - should not have the quotes I believe (change is needed in=20 > > > several > > > places) > > > Content-Type: application/yang+data+json > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > Replace > > > The "insert" query parameter discussed in Section 4.8.5 of = [RFC8040] > > > MAY be used to specify how a ACE is inserted within an ACL and = how a > > > ACL is inserted within an ACL list. > > > With - ACL Lists are not configured to be ordered > > > The "insert" query parameter discussed in Section 4.8.5 of = [RFC8040] > > > MAY be used to specify how a ACE is inserted within an ACL and = how a > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > [Med] I made some minor changes to your proposal: > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be = used > > to specify how an Access Control Entry (ACE) is inserted within = an > > ACL and how an ACL is inserted within an ACL set in container = dots- > > acl-order. > > [Jon] Works for me > > > > > As part of another discussion on the use of client-identifiers, I=20 > > > am not happy with (it is too restrictive). The draft elsewhere=20 > > > refers to the control of IPs being revealed > > > > > > In order to prevent leaking internal information outside a = client- > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity = of > > > internal DOTS clients (client-identifier) unless explicitly > > > configured to do so. > > > > > > > [Med] Is it too restrictive? > > > > It does set the bar where an administrator has to instruct the=20 > > gateway explicitly about the information to be inserted/leaked. > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > [Jon] This follows on from our other discussions about client- > identifiers > > - > > which actually do not reveal the identity of the client (there is no = > > IP information, the unique information about the client is one way=20 > > hashed into the client-identifier). That said, the DOTS server can=20 > > work out how > many > > clients there actually are behind the gateway and which of them are=20 > > more active, but I do not see this as a real security risk. All=20 > > traffic is encrypted, making it difficult for any other device to=20 > > work out what is going on. Without the client-identifier (or some alternative "mangling" > > of > > the mitigation ids to provide uniqueness) the DOTS server cannot=20 > > effectively / correctly handle the same mitigation-id when requested = > > /used by different DOTS clients. > > > > >=20 > [Med] In order to keep this text (and its initial intent) aside from=20 > the client-id discussion. I suggest to make this change: >=20 > In order to prevent leaking internal information outside a client- > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > internal DOTS clients (e.g., source IP address) unless explicitly > configured to do so. >=20 > We may update based on the conclusion of the client-id discussion. >=20 > Hope this is OK with you. >=20 > Please double check at: https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draf > t- > ietf-dots-data-channel-12.pdf >=20 > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 09:11 > > > To: dots@ietf.org > > > Cc: JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi all, > > > > > > Christian has kindly reviewed this version of the draft. Many=20 > > > thanks to him. > > > > > > > > > Proposed changes are available at: > > > https://github.com/boucadair/IETF-Drafts- > > > Reviews/blob/master/wdiff%20draft-i > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre = 2017=20 > > > > 16:37 > =C0=A0: > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > The main changes in this version are as follows: > > > > - Remove target-ip because it is redundant with target-prefix > > > > - Indicate that the order of establishing signal/data channel is = > > > > implementation/deployment specific > > > > - Mention that the signal channel I-D is the authoritative=20 > > > > reference for manipulating client-id; the data channel must=20 > > > > follow the signal channel spec. > > > > - Add a discussion about translation implications > > > > - Add conflict support > > > > - The same resource can be associated with different aliases if=20 > > > > multiple dots clients are deployed within a network > > > > - Check the normative language > > > > > > > > Please review and share comments. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre = 2017 16:32 =C0=A0: > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] = I-D > Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > > Internet-Drafts directories. > > > > > This draft is a work item of the DDoS Open Threat Signaling WG = > > > > > of the IETF. > > > > > > > > > > Title : Distributed Denial-of-Service Open > Threat > > > > > Signaling (DOTS) Data Channel > > > > > Authors : Tirumaleswar Reddy > > > > > Mohamed Boucadair > > > > > Kaname Nishizuka > > > > > Liang Xia > > > > > Prashanth Patil > > > > > Andrew Mortensen > > > > > Nik Teague > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > Pages : 31 > > > > > Date : 2017-12-18 > > > > > > > > > > Abstract: > > > > > The document specifies a Distributed Denial-of-Service Open > > Threat > > > > > Signaling (DOTS) data channel used for bulk exchange of=20 > > > > > data > not > > > > > easily or appropriately communicated through the DOTS=20 > > > > > signal > > > channel > > > > > under attack conditions. > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > specification. > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > Please update these statements with the RFC number to be=20 > > > > > assigned > > > to > > > > > this document: > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > Signaling > > > > > (DOTS) Data Channel"; > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-cha > > > > > nnel > > > > > -1 > > > > > 1 > > > > > > > > > > A diff from the previous version is available at: > > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel > > > > > -11 > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time = > > > > > of submission until the htmlized version and diff are=20 > > > > > available at tools.ietf.org. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 05:18:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292A7126BFD for ; Wed, 20 Dec 2017 05:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWL7HRCxqr0k for ; Wed, 20 Dec 2017 05:18:47 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CCA12422F for ; Wed, 20 Dec 2017 05:18:46 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 9A8F120366; Wed, 20 Dec 2017 14:18:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 76C2A1A0093; Wed, 20 Dec 2017 14:18:45 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 14:18:40 +0100 From: To: Jon Shallow , "dots@ietf.org" , JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyaJbcS6ggAADt+A= Date: Wed, 20 Dec 2017 13:18:39 +0000 Message-ID: <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> In-Reply-To: <051101d37993$c1d21380$45763a80$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:18:49 -0000 Re-, I'm hesitating to add "reject" in the context for DDoS because it will requ= ire sending ICMP messages to (misbehaving) sources. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian IMT= /OLN > Objet=A0: RE: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > See inline [Jon1]. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: -bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 20 December 2017 12:56 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR Mohame= d > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: [Dots= ] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > See inline [Jon] > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' should > > really be called 'acl-set-name' and 'acl-set-type' respectively in all > > the appropriate reference points. >=20 > [Med] Please note that as per YANG naming conventions, there is little > value > in repeating names in a given hierarchy. I'm sure this will be a comment > we > will get from yangdoctors if we change the names as you suggest. > [Jon1] Fair enough >=20 >=20 > > > > augment /ietf-acl:access-lists: > > +--rw dots-acl-order > > +--rw acl-set* [set-name type] > > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-name > > +--rw acl-set-type -> /ietf-acl:access-lists/acl/acl-typ= e > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 11:58 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Hi Jon, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR Moha= med > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > You need to update the following in the diff pdf > > > > > > 1. Introduction > > > > > > Replace > > > ... from these sites is protected from DDoS attacks. The DOTS > > > client uses the.... > > > with > > > ... from these sites is protected from DDoS attack mitigation. The > > > DOTS client uses the.... > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > [Jon] The context here is white-listed IPs - the whitelisted IPs > > should not get mitigated, not protected from DDoS attacks. So, 'yes'. > > [Jon] I should have added in the rest of the line "The DOTS client > > uses the DOTS data channel to convey the white-listed IP prefixes of > > the partner sites to its DOTS server." > > > > > Otherwise > > > > > > 7.1 Install Filtering rules > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > Should this be added? > [Jon1] you have not responded to this question > > > > > > Replace > > > Content-Type: "application/yang+data+json" > > > With - should not have the quotes I believe (change is needed in > > > several > > > places) > > > Content-Type: application/yang+data+json > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > Replace > > > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040= ] > > > MAY be used to specify how a ACE is inserted within an ACL and how = a > > > ACL is inserted within an ACL list. > > > With - ACL Lists are not configured to be ordered > > > The "insert" query parameter discussed in Section 4.8.5 of [RFC8040= ] > > > MAY be used to specify how a ACE is inserted within an ACL and how = a > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > [Med] I made some minor changes to your proposal: > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be use= d > > to specify how an Access Control Entry (ACE) is inserted within an > > ACL and how an ACL is inserted within an ACL set in container dots- > > acl-order. > > [Jon] Works for me > > > > > As part of another discussion on the use of client-identifiers, I am > > > not happy with (it is too restrictive). The draft elsewhere refers > > > to the control of IPs being revealed > > > > > > In order to prevent leaking internal information outside a client- > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > > > internal DOTS clients (client-identifier) unless explicitly > > > configured to do so. > > > > > > > [Med] Is it too restrictive? > > > > It does set the bar where an administrator has to instruct the gateway > > explicitly about the information to be inserted/leaked. > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > [Jon] This follows on from our other discussions about > > client-identifiers > > - > > which actually do not reveal the identity of the client (there is no > > IP information, the unique information about the client is one way > > hashed into the client-identifier). That said, the DOTS server can > > work out how many clients there actually are behind the gateway and > > which of them are more active, but I do not see this as a real > > security risk. All traffic is encrypted, making it difficult for any > > other device to work out what is going on. Without the > > client-identifier (or some alternative "mangling" > > of > > the mitigation ids to provide uniqueness) the DOTS server cannot > > effectively / correctly handle the same mitigation-id when requested > > /used by different DOTS clients. > > > > >=20 > [Med] In order to keep this text (and its initial intent) aside from the > client-id discussion. I suggest to make this change: >=20 > In order to prevent leaking internal information outside a client- > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > internal DOTS clients (e.g., source IP address) unless explicitly > configured to do so. >=20 > We may update based on the conclusion of the client-id discussion. >=20 > Hope this is OK with you. > [Jon1] Yes, this is a good initial move for me. >=20 > Please double check at: > https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/wdiff%20draft-i > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > [Jon1] Apart from one thing above, you have captured this email thread. >=20 > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 09:11 > > > To: dots@ietf.org > > > Cc: JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi all, > > > > > > Christian has kindly reviewed this version of the draft. Many thanks > > > to him. > > > > > > > > > Proposed changes are available at: > > > https://github.com/boucadair/IETF-Drafts- > > > Reviews/blob/master/wdiff%20draft-i > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2017 = 16:37 > =C0=A0: > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > The main changes in this version are as follows: > > > > - Remove target-ip because it is redundant with target-prefix > > > > - Indicate that the order of establishing signal/data channel is > > > > implementation/deployment specific > > > > - Mention that the signal channel I-D is the authoritative > > > > reference for manipulating client-id; the data channel must follow > > > > the signal channel spec. > > > > - Add a discussion about translation implications > > > > - Add conflict support > > > > - The same resource can be associated with different aliases if > > > > multiple dots clients are deployed within a network > > > > - Check the normative language > > > > > > > > Please review and share comments. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet= - > > > > > drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017 16:32 =C0= =A0: > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D > Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. > > > > > This draft is a work item of the DDoS Open Threat Signaling WG > > > > > of the IETF. > > > > > > > > > > Title : Distributed Denial-of-Service Open > Threat > > > > > Signaling (DOTS) Data Channel > > > > > Authors : Tirumaleswar Reddy > > > > > Mohamed Boucadair > > > > > Kaname Nishizuka > > > > > Liang Xia > > > > > Prashanth Patil > > > > > Andrew Mortensen > > > > > Nik Teague > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > Pages : 31 > > > > > Date : 2017-12-18 > > > > > > > > > > Abstract: > > > > > The document specifies a Distributed Denial-of-Service Open > > Threat > > > > > Signaling (DOTS) data channel used for bulk exchange of data > not > > > > > easily or appropriately communicated through the DOTS signal > > > channel > > > > > under attack conditions. > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > specification. > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > Please update these statements with the RFC number to be > > > > > assigned > > > to > > > > > this document: > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > Signaling > > > > > (DOTS) Data Channel"; > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-chann > > > > > el > > > > > -1 > > > > > 1 > > > > > > > > > > A diff from the previous version is available at: > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-= 1 > > > > > 1 > > > > > > > > > > > > > > > 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. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 05:28:23 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B192127337 for ; Wed, 20 Dec 2017 05:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j-CCMw0tVqN for ; Wed, 20 Dec 2017 05:28:17 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486EE126CC7 for ; Wed, 20 Dec 2017 05:28:17 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRePv-000628-OR; Wed, 20 Dec 2017 13:28:15 +0000 From: "Jon Shallow" To: , , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> In-Reply-To: <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> Date: Wed, 20 Dec 2017 13:28:16 -0000 Message-ID: <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyQI0LseCAS4vHlWiQGTUwA== Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:28:19 -0000 Hi Med, Good point. I have discussed with Tiru in the past about nominating a subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think is irrelevant), and it may sense to also have a "never to use" subset list. Regards Jon -----Original Message----- From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 20 December 2017 13:19 To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Re-, I'm hesitating to add "reject" in the context for DDoS because it will require sending ICMP messages to (misbehaving) sources. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR = Mohamed=20 > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: = [Dots]=20 > TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > See inline [Jon1]. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: -bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 20 December 2017 12:56 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action:=20 > draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR = Mohamed=20 > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE:=20 > > [Dots] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > See inline [Jon] > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' should=20 > > really be called 'acl-set-name' and 'acl-set-type' respectively in=20 > > all the appropriate reference points. >=20 > [Med] Please note that as per YANG naming conventions, there is little = > value in repeating names in a given hierarchy. I'm sure this will be a = > comment we will get from yangdoctors if we change the names as you=20 > suggest. > [Jon1] Fair enough >=20 >=20 > > > > augment /ietf-acl:access-lists: > > +--rw dots-acl-order > > +--rw acl-set* [set-name type] > > +--rw acl-set-name -> = /ietf-acl:access-lists/acl/acl-name > > +--rw acl-set-type -> = /ietf-acl:access-lists/acl/acl-type > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 11:58 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Hi Jon, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR = Mohamed=20 > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > You need to update the following in the diff pdf > > > > > > 1. Introduction > > > > > > Replace > > > ... from these sites is protected from DDoS attacks. The DOTS=20 > > > client uses the.... > > > with > > > ... from these sites is protected from DDoS attack mitigation.=20 > > > The DOTS client uses the.... > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > [Jon] The context here is white-listed IPs - the whitelisted IPs=20 > > should not get mitigated, not protected from DDoS attacks. So, = 'yes'. > > [Jon] I should have added in the rest of the line "The DOTS client=20 > > uses the DOTS data channel to convey the white-listed IP prefixes=20 > > of the partner sites to its DOTS server." > > > > > Otherwise > > > > > > 7.1 Install Filtering rules > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > Should this be added? > [Jon1] you have not responded to this question > > > > > > Replace > > > Content-Type: "application/yang+data+json" > > > With - should not have the quotes I believe (change is needed in=20 > > > several > > > places) > > > Content-Type: application/yang+data+json > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > Replace > > > The "insert" query parameter discussed in Section 4.8.5 of = [RFC8040] > > > MAY be used to specify how a ACE is inserted within an ACL and = how a > > > ACL is inserted within an ACL list. > > > With - ACL Lists are not configured to be ordered > > > The "insert" query parameter discussed in Section 4.8.5 of = [RFC8040] > > > MAY be used to specify how a ACE is inserted within an ACL and = how a > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > [Med] I made some minor changes to your proposal: > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be = used > > to specify how an Access Control Entry (ACE) is inserted within = an > > ACL and how an ACL is inserted within an ACL set in container = dots- > > acl-order. > > [Jon] Works for me > > > > > As part of another discussion on the use of client-identifiers, I=20 > > > am not happy with (it is too restrictive). The draft elsewhere=20 > > > refers to the control of IPs being revealed > > > > > > In order to prevent leaking internal information outside a = client- > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity = of > > > internal DOTS clients (client-identifier) unless explicitly > > > configured to do so. > > > > > > > [Med] Is it too restrictive? > > > > It does set the bar where an administrator has to instruct the=20 > > gateway explicitly about the information to be inserted/leaked. > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > [Jon] This follows on from our other discussions about=20 > > client-identifiers > > - > > which actually do not reveal the identity of the client (there is no = > > IP information, the unique information about the client is one way=20 > > hashed into the client-identifier). That said, the DOTS server can=20 > > work out how many clients there actually are behind the gateway and=20 > > which of them are more active, but I do not see this as a real=20 > > security risk. All traffic is encrypted, making it difficult for=20 > > any other device to work out what is going on. Without the=20 > > client-identifier (or some alternative "mangling" > > of > > the mitigation ids to provide uniqueness) the DOTS server cannot=20 > > effectively / correctly handle the same mitigation-id when requested = > > /used by different DOTS clients. > > > > >=20 > [Med] In order to keep this text (and its initial intent) aside from=20 > the client-id discussion. I suggest to make this change: >=20 > In order to prevent leaking internal information outside a client- > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > internal DOTS clients (e.g., source IP address) unless explicitly > configured to do so. >=20 > We may update based on the conclusion of the client-id discussion. >=20 > Hope this is OK with you. > [Jon1] Yes, this is a good initial move for me. >=20 > Please double check at: > https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/wdiff%20draft-i > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > [Jon1] Apart from one thing above, you have captured this email = thread. >=20 > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 09:11 > > > To: dots@ietf.org > > > Cc: JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi all, > > > > > > Christian has kindly reviewed this version of the draft. Many=20 > > > thanks to him. > > > > > > > > > Proposed changes are available at: > > > https://github.com/boucadair/IETF-Drafts- > > > Reviews/blob/master/wdiff%20draft-i > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre = 2017=20 > > > > 16:37 > =C0=A0: > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > The main changes in this version are as follows: > > > > - Remove target-ip because it is redundant with target-prefix > > > > - Indicate that the order of establishing signal/data channel is = > > > > implementation/deployment specific > > > > - Mention that the signal channel I-D is the authoritative=20 > > > > reference for manipulating client-id; the data channel must=20 > > > > follow the signal channel spec. > > > > - Add a discussion about translation implications > > > > - Add conflict support > > > > - The same resource can be associated with different aliases if=20 > > > > multiple dots clients are deployed within a network > > > > - Check the normative language > > > > > > > > Please review and share comments. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre = 2017 16:32 =C0=A0: > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] = I-D > Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > > Internet-Drafts directories. > > > > > This draft is a work item of the DDoS Open Threat Signaling WG = > > > > > of the IETF. > > > > > > > > > > Title : Distributed Denial-of-Service Open > Threat > > > > > Signaling (DOTS) Data Channel > > > > > Authors : Tirumaleswar Reddy > > > > > Mohamed Boucadair > > > > > Kaname Nishizuka > > > > > Liang Xia > > > > > Prashanth Patil > > > > > Andrew Mortensen > > > > > Nik Teague > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > Pages : 31 > > > > > Date : 2017-12-18 > > > > > > > > > > Abstract: > > > > > The document specifies a Distributed Denial-of-Service Open > > Threat > > > > > Signaling (DOTS) data channel used for bulk exchange of=20 > > > > > data > not > > > > > easily or appropriately communicated through the DOTS=20 > > > > > signal > > > channel > > > > > under attack conditions. > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > specification. > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > Please update these statements with the RFC number to be=20 > > > > > assigned > > > to > > > > > this document: > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > Signaling > > > > > (DOTS) Data Channel"; > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-cha > > > > > nn > > > > > el > > > > > -1 > > > > > 1 > > > > > > > > > > A diff from the previous version is available at: > > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel > > > > > -1 > > > > > 1 > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time = > > > > > of submission until the htmlized version and diff are=20 > > > > > available at tools.ietf.org. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 06:07:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB1129C6F for ; Wed, 20 Dec 2017 06:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xn4FFjidUv0 for ; Wed, 20 Dec 2017 06:07:52 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0383F126CD6 for ; Wed, 20 Dec 2017 06:07:51 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 415A01C0D43; Wed, 20 Dec 2017 15:07:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 1BCD780072; Wed, 20 Dec 2017 15:07:50 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 15:07:46 +0100 From: To: Jon Shallow , "dots@ietf.org" , JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyQI0LseCAS4vHlWiQGTUwIAAA3FQ Date: Wed, 20 Dec 2017 14:07:46 +0000 Message-ID: <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> In-Reply-To: <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 14:07:55 -0000 Re-, Providing some guidance to implementers is helpful, IMO.=20 The ACL YANG module defines these features:=20 * l2-acl * mixed-ipv4-acl * mixed-ipv6-acl * l2-l3-ipv4-ipv6-acl * tcp-acl * udp-acl * icmp-acl * any-acl * interface-stats We can indicate that in the context of DOTS, the following features MUST be= supported: * ipv4-acl=20 * ipv6-acl * tcp-acl * udp-acl * icmp-acl This branch of the module MUST NOT be implemented because we are not touchi= ng interfaces: +--rw interfaces=20 I would be silent about the other features. We can discourage from using "reject" action.=20 I can draft some text among those lines, if needed.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:28 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian IMT= /OLN > Objet=A0: RE: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > Good point. I have discussed with Tiru in the past about nominating a > subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think is > irrelevant), and it may sense to also have a "never to use" subset list. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of > ietf-supjps-mohamed.boucadair@orange.com > Sent: 20 December 2017 13:19 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > I'm hesitating to add "reject" in the context for DDoS because it will > require sending ICMP messages to (misbehaving) sources. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR Mohame= d > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: [Dots= ] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > See inline [Jon1]. > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: -bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 12:56 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR Moha= med > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > See inline [Jon] > > > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' should > > > really be called 'acl-set-name' and 'acl-set-type' respectively in > > > all the appropriate reference points. > > > > [Med] Please note that as per YANG naming conventions, there is little > > value in repeating names in a given hierarchy. I'm sure this will be a > > comment we will get from yangdoctors if we change the names as you > > suggest. > > [Jon1] Fair enough > > > > > > > > > > augment /ietf-acl:access-lists: > > > +--rw dots-acl-order > > > +--rw acl-set* [set-name type] > > > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-nam= e > > > +--rw acl-set-type -> /ietf-acl:access-lists/acl/acl- > type > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 11:58 > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi Jon, > > > > > > Thank you for the comments. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR Mo= hamed > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > [Dots] > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Med, > > > > > > > > You need to update the following in the diff pdf > > > > > > > > 1. Introduction > > > > > > > > Replace > > > > ... from these sites is protected from DDoS attacks. The DOTS > > > > client uses the.... > > > > with > > > > ... from these sites is protected from DDoS attack mitigation. > > > > The DOTS client uses the.... > > > > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > > [Jon] The context here is white-listed IPs - the whitelisted IPs > > > should not get mitigated, not protected from DDoS attacks. So, 'yes'. > > > [Jon] I should have added in the rest of the line "The DOTS client > > > uses the DOTS data channel to convey the white-listed IP prefixes > > > of the partner sites to its DOTS server." > > > > > > > Otherwise > > > > > > > > 7.1 Install Filtering rules > > > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > > Should this be added? > > [Jon1] you have not responded to this question > > > > > > > > Replace > > > > Content-Type: "application/yang+data+json" > > > > With - should not have the quotes I believe (change is needed in > > > > several > > > > places) > > > > Content-Type: application/yang+data+json > > > > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > Replace > > > > The "insert" query parameter discussed in Section 4.8.5 of > [RFC8040] > > > > MAY be used to specify how a ACE is inserted within an ACL and ho= w > a > > > > ACL is inserted within an ACL list. > > > > With - ACL Lists are not configured to be ordered > > > > The "insert" query parameter discussed in Section 4.8.5 of > [RFC8040] > > > > MAY be used to specify how a ACE is inserted within an ACL and ho= w > a > > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > > > > [Med] I made some minor changes to your proposal: > > > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be > used > > > to specify how an Access Control Entry (ACE) is inserted within an > > > ACL and how an ACL is inserted within an ACL set in container dots= - > > > acl-order. > > > [Jon] Works for me > > > > > > > As part of another discussion on the use of client-identifiers, I > > > > am not happy with (it is too restrictive). The draft elsewhere > > > > refers to the control of IPs being revealed > > > > > > > > In order to prevent leaking internal information outside a client= - > > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity > of > > > > internal DOTS clients (client-identifier) unless explicitly > > > > configured to do so. > > > > > > > > > > [Med] Is it too restrictive? > > > > > > It does set the bar where an administrator has to instruct the > > > gateway explicitly about the information to be inserted/leaked. > > > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > > > [Jon] This follows on from our other discussions about > > > client-identifiers > > > - > > > which actually do not reveal the identity of the client (there is no > > > IP information, the unique information about the client is one way > > > hashed into the client-identifier). That said, the DOTS server can > > > work out how many clients there actually are behind the gateway and > > > which of them are more active, but I do not see this as a real > > > security risk. All traffic is encrypted, making it difficult for > > > any other device to work out what is going on. Without the > > > client-identifier (or some alternative "mangling" > > > of > > > the mitigation ids to provide uniqueness) the DOTS server cannot > > > effectively / correctly handle the same mitigation-id when requested > > > /used by different DOTS clients. > > > > > > > > > > [Med] In order to keep this text (and its initial intent) aside from > > the client-id discussion. I suggest to make this change: > > > > In order to prevent leaking internal information outside a client- > > domain, client-side DOTS gateways SHOULD NOT reveal the identity of > > internal DOTS clients (e.g., source IP address) unless explicitly > > configured to do so. > > > > We may update based on the conclusion of the client-id discussion. > > > > Hope this is OK with you. > > [Jon1] Yes, this is a good initial move for me. > > > > Please double check at: > > https://github.com/boucadair/IETF-Drafts- > > Reviews/blob/master/wdiff%20draft-i > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > [Jon1] Apart from one thing above, you have captured this email thread. > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 20 December 2017 09:11 > > > > To: dots@ietf.org > > > > Cc: JACQUENET Christian IMT/OLN > > > > Subject: Re: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi all, > > > > > > > > Christian has kindly reviewed this version of the draft. Many > > > > thanks to him. > > > > > > > > > > > > Proposed changes are available at: > > > > https://github.com/boucadair/IETF-Drafts- > > > > Reviews/blob/master/wdiff%20draft-i > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 201= 7 > > > > > 16:37 > > =C0=A0: > > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Re-, > > > > > > > > > > The main changes in this version are as follows: > > > > > - Remove target-ip because it is redundant with target-prefix > > > > > - Indicate that the order of establishing signal/data channel is > > > > > implementation/deployment specific > > > > > - Mention that the signal channel I-D is the authoritative > > > > > reference for manipulating client-id; the data channel must > > > > > follow the signal channel spec. > > > > > - Add a discussion about translation implications > > > > > - Add conflict support > > > > > - The same resource can be associated with different aliases if > > > > > multiple dots clients are deployed within a network > > > > > - Check the normative language > > > > > > > > > > Please review and share comments. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 2017= 16:32 > =C0=A0: > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D > > Action: > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts directories. > > > > > > This draft is a work item of the DDoS Open Threat Signaling WG > > > > > > of the IETF. > > > > > > > > > > > > Title : Distributed Denial-of-Service Open > > Threat > > > > > > Signaling (DOTS) Data Channel > > > > > > Authors : Tirumaleswar Reddy > > > > > > Mohamed Boucadair > > > > > > Kaname Nishizuka > > > > > > Liang Xia > > > > > > Prashanth Patil > > > > > > Andrew Mortensen > > > > > > Nik Teague > > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > > Pages : 31 > > > > > > Date : 2017-12-18 > > > > > > > > > > > > Abstract: > > > > > > The document specifies a Distributed Denial-of-Service Open > > > Threat > > > > > > Signaling (DOTS) data channel used for bulk exchange of > > > > > > data > > not > > > > > > easily or appropriately communicated through the DOTS > > > > > > signal > > > > channel > > > > > > under attack conditions. > > > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > > specification. > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > Please update these statements with the RFC number to be > > > > > > assigned > > > > to > > > > > > this document: > > > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > > Signaling > > > > > > (DOTS) Data Channel"; > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-cha > > > > > > nn > > > > > > el > > > > > > -1 > > > > > > 1 > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channe= l > > > > > > -1 > > > > > > 1 > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 06:29:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCAB126579 for ; Wed, 20 Dec 2017 06:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ8oblg76ZKX for ; Wed, 20 Dec 2017 06:29:15 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29BD1201F8 for ; Wed, 20 Dec 2017 06:29:14 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRfMv-00063v-Ca; Wed, 20 Dec 2017 14:29:13 +0000 From: "Jon Shallow" To: , , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> In-Reply-To: <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> Date: Wed, 20 Dec 2017 14:29:14 -0000 Message-ID: <052301d3799e$e8f3c5c0$badb5140$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyQI0LseCAS4vHlUBRtT+lgIXfanwoiWDd7A= Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 14:29:17 -0000 Hi Med, I think this would be helpful to implementers so that they know the = minimum of what should be supported. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 20 December 2017 14:08 To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Re-, Providing some guidance to implementers is helpful, IMO.=20 The ACL YANG module defines these features:=20 * l2-acl * mixed-ipv4-acl * mixed-ipv6-acl * l2-l3-ipv4-ipv6-acl * tcp-acl * udp-acl * icmp-acl * any-acl * interface-stats We can indicate that in the context of DOTS, the following features MUST = be supported: * ipv4-acl * ipv6-acl * tcp-acl * udp-acl * icmp-acl This branch of the module MUST NOT be implemented because we are not touching interfaces: +--rw interfaces=20 I would be silent about the other features. We can discourage from using "reject" action.=20 I can draft some text among those lines, if needed.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:28 =C0=A0: BOUCADAIR = Mohamed=20 > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: = [Dots]=20 > TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > Good point. I have discussed with Tiru in the past about nominating a = > subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think=20 > is irrelevant), and it may sense to also have a "never to use" subset list. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 20 December 2017 13:19 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action:=20 > draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > I'm hesitating to add "reject" in the context for DDoS because it will = > require sending ICMP messages to (misbehaving) sources. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR = Mohamed=20 > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE:=20 > > [Dots] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > See inline [Jon1]. > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: -bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 12:56 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR = Mohamed=20 > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > See inline [Jon] > > > > > > In addition, I think that 'set-name' and 'type' in 'acl-set'=20 > > > should really be called 'acl-set-name' and 'acl-set-type'=20 > > > respectively in all the appropriate reference points. > > > > [Med] Please note that as per YANG naming conventions, there is=20 > > little value in repeating names in a given hierarchy. I'm sure this=20 > > will be a comment we will get from yangdoctors if we change the=20 > > names as you suggest. > > [Jon1] Fair enough > > > > > > > > > > augment /ietf-acl:access-lists: > > > +--rw dots-acl-order > > > +--rw acl-set* [set-name type] > > > +--rw acl-set-name -> = /ietf-acl:access-lists/acl/acl-name > > > +--rw acl-set-type -> = /ietf-acl:access-lists/acl/acl- > type > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 11:58 > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi Jon, > > > > > > Thank you for the comments. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR = Mohamed=20 > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: = RE: > > > > [Dots] > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Med, > > > > > > > > You need to update the following in the diff pdf > > > > > > > > 1. Introduction > > > > > > > > Replace > > > > ... from these sites is protected from DDoS attacks. The DOTS=20 > > > > client uses the.... > > > > with > > > > ... from these sites is protected from DDoS attack mitigation. > > > > The DOTS client uses the.... > > > > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > > [Jon] The context here is white-listed IPs - the whitelisted IPs=20 > > > should not get mitigated, not protected from DDoS attacks. So, = 'yes'. > > > [Jon] I should have added in the rest of the line "The DOTS client = > > > uses the DOTS data channel to convey the white-listed IP prefixes = > > > of the partner sites to its DOTS server." > > > > > > > Otherwise > > > > > > > > 7.1 Install Filtering rules > > > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > > Should this be added? > > [Jon1] you have not responded to this question > > > > > > > > Replace > > > > Content-Type: "application/yang+data+json" > > > > With - should not have the quotes I believe (change is needed in = > > > > several > > > > places) > > > > Content-Type: application/yang+data+json > > > > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > Replace > > > > The "insert" query parameter discussed in Section 4.8.5 of > [RFC8040] > > > > MAY be used to specify how a ACE is inserted within an ACL and = > > > > how > a > > > > ACL is inserted within an ACL list. > > > > With - ACL Lists are not configured to be ordered > > > > The "insert" query parameter discussed in Section 4.8.5 of > [RFC8040] > > > > MAY be used to specify how a ACE is inserted within an ACL and = > > > > how > a > > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > > > > [Med] I made some minor changes to your proposal: > > > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY=20 > > > be > used > > > to specify how an Access Control Entry (ACE) is inserted within = an > > > ACL and how an ACL is inserted within an ACL set in container = dots- > > > acl-order. > > > [Jon] Works for me > > > > > > > As part of another discussion on the use of client-identifiers,=20 > > > > I am not happy with (it is too restrictive). The draft=20 > > > > elsewhere refers to the control of IPs being revealed > > > > > > > > In order to prevent leaking internal information outside a = client- > > > > domain, client-side DOTS gateways SHOULD NOT reveal the=20 > > > > identity > of > > > > internal DOTS clients (client-identifier) unless explicitly > > > > configured to do so. > > > > > > > > > > [Med] Is it too restrictive? > > > > > > It does set the bar where an administrator has to instruct the=20 > > > gateway explicitly about the information to be inserted/leaked. > > > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > > > [Jon] This follows on from our other discussions about=20 > > > client-identifiers > > > - > > > which actually do not reveal the identity of the client (there is=20 > > > no IP information, the unique information about the client is one=20 > > > way hashed into the client-identifier). That said, the DOTS=20 > > > server can work out how many clients there actually are behind the = > > > gateway and which of them are more active, but I do not see this=20 > > > as a real security risk. All traffic is encrypted, making it=20 > > > difficult for any other device to work out what is going on. =20 > > > Without the client-identifier (or some alternative "mangling" > > > of > > > the mitigation ids to provide uniqueness) the DOTS server cannot=20 > > > effectively / correctly handle the same mitigation-id when=20 > > > requested /used by different DOTS clients. > > > > > > > > > > [Med] In order to keep this text (and its initial intent) aside from = > > the client-id discussion. I suggest to make this change: > > > > In order to prevent leaking internal information outside a = client- > > domain, client-side DOTS gateways SHOULD NOT reveal the identity = of > > internal DOTS clients (e.g., source IP address) unless explicitly > > configured to do so. > > > > We may update based on the conclusion of the client-id discussion. > > > > Hope this is OK with you. > > [Jon1] Yes, this is a good initial move for me. > > > > Please double check at: > > https://github.com/boucadair/IETF-Drafts- > > Reviews/blob/master/wdiff%20draft-i > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > [Jon1] Apart from one thing above, you have captured this email = thread. > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > mohamed.boucadair@orange.com > > > > Sent: 20 December 2017 09:11 > > > > To: dots@ietf.org > > > > Cc: JACQUENET Christian IMT/OLN > > > > Subject: Re: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi all, > > > > > > > > Christian has kindly reviewed this version of the draft. Many=20 > > > > thanks to him. > > > > > > > > > > > > Proposed changes are available at: > > > > https://github.com/boucadair/IETF-Drafts- > > > > Reviews/blob/master/wdiff%20draft-i > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.p > > > > df > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de=20 > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre = 2017 > > > > > 16:37 > > =C0=A0: > > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Re-, > > > > > > > > > > The main changes in this version are as follows: > > > > > - Remove target-ip because it is redundant with target-prefix > > > > > - Indicate that the order of establishing signal/data channel=20 > > > > > is implementation/deployment specific > > > > > - Mention that the signal channel I-D is the authoritative=20 > > > > > reference for manipulating client-id; the data channel must=20 > > > > > follow the signal channel spec. > > > > > - Add a discussion about translation implications > > > > > - Add conflict support > > > > > - The same resource can be associated with different aliases=20 > > > > > if multiple dots clients are deployed within a network > > > > > - Check the normative language > > > > > > > > > > Please review and share comments. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre = 2017=20 > > > > > > 16:32 > =C0=A0: > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] = I-D > > Action: > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > > > Internet-Drafts directories. > > > > > > This draft is a work item of the DDoS Open Threat Signaling=20 > > > > > > WG of the IETF. > > > > > > > > > > > > Title : Distributed Denial-of-Service Open > > Threat > > > > > > Signaling (DOTS) Data Channel > > > > > > Authors : Tirumaleswar Reddy > > > > > > Mohamed Boucadair > > > > > > Kaname Nishizuka > > > > > > Liang Xia > > > > > > Prashanth Patil > > > > > > Andrew Mortensen > > > > > > Nik Teague > > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > > Pages : 31 > > > > > > Date : 2017-12-18 > > > > > > > > > > > > Abstract: > > > > > > The document specifies a Distributed Denial-of-Service=20 > > > > > > Open > > > Threat > > > > > > Signaling (DOTS) data channel used for bulk exchange of=20 > > > > > > data > > not > > > > > > easily or appropriately communicated through the DOTS=20 > > > > > > signal > > > > channel > > > > > > under attack conditions. > > > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > > specification. > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > Please update these statements with the RFC number to be=20 > > > > > > assigned > > > > to > > > > > > this document: > > > > > > > > > > > > o "This version of this YANG module is part of RFC = XXXX;" > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > > Signaling > > > > > > (DOTS) Data Channel"; > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channe > > > > > > l/ > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-c > > > > > > ha > > > > > > nn > > > > > > el > > > > > > -1 > > > > > > 1 > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-chann > > > > > > el > > > > > > -1 > > > > > > 1 > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the=20 > > > > > > time of submission until the htmlized version and diff are=20 > > > > > > available at tools.ietf.org. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Dec 20 19:10:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E25124F57 for ; Wed, 20 Dec 2017 19:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zzvDnmJ067w for ; Wed, 20 Dec 2017 19:10:18 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E4C1242EA for ; Wed, 20 Dec 2017 19:10:17 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513825802; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=h YrROOPtOormtmuLSMdmstA2lVzdzgUmNXeO24rvkW M=; b=mFCnF3UrW2oa4dgd6VR8MViTnJW6TJBSKLHjPQXI1QrD hc9t3PQ/n3NCrnFJ72mWlUyfLuh6mLVuaDTVLCgONszGrPrBaE UYzp5rj5S8GMqHQFTboXeHqDlZz3BDtA523c4j5cxeJj7Qbyl7 HaCe1QM7H8genPX2hZsYW2vIGP0= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 39b0_a976_5544e575_c56d_466b_837a_804fb4c00275; Wed, 20 Dec 2017 21:10:01 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 20:09:53 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 20 Dec 2017 20:09:53 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 20:09:52 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Thu, 21 Dec 2017 03:09:51 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0323.018; Thu, 21 Dec 2017 03:09:51 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "christian.jacquenet@orange.com" Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQHTeBYrfA5l02glEU6495oM3LXs4KNL9KUAgAASYwCAABxmgIAABvsAgAAJHgCAAAPPAIAAApaAgAACsACAAAsJAIAABgAAgADUXbA= Date: Thu, 21 Dec 2017 03:09:50 +0000 Message-ID: References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> <052301d3799e$e8f3c5c0$badb5140$@jpshallow.com> In-Reply-To: <052301d3799e$e8f3c5c0$badb5140$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:YR4SzutlSAnCI57T7jo9uxlTp4SdUTCjwB2AfeHMSYjeLTffQbc5vH3Bs1oGCAgDR6kpOhmmqKInkzY0g0xjrsXPukz2UPagPbjPGGIQDXBmIUfMsUC/UVPizuzacZf+jxg4RFVMyQBR3ICqNsW6zQFnVWYz48jmCt6Ddowq8bJb/Aqcff09+UdUZgItlXWioZf4HBaKpyPLOnkvIz2SzoBvbFrVV0vQVYGZX3AuiVMMnw4kkKltTWD9tZLGBFmLZeHoE7sBehhe5gICuTpBdLWHX8PH8DKVKLNRjpnIkrc07D1l64kyCFYsbKGQ92cdBOY1j/d1Gb1EQsuOxrER5UONQ7pmHrVJCswIOBKW5pI=; 5:caY6IApNRkkr1x85IGkI9SF8wcqEDmim0jxZEoi2RGFIAxzcfnVLi0r/mQy+3W7XPt7rfTrAo+LkmScK8lzAWFKprs67zfAR0EaHYNu64TtCnK+o5kE+8YMAsa85cNA7eMZKWch0WPZySXKSZu/BOfrvXxttSzHbo4F1rKm3SVA=; 24:zqV4kjadyg4+YOwjjakC/XoU6oVl5tkPV2yLFjq/GaxvWV6REHRcb39+kXb0krTCRNU1OTYcK116V2QqStKuaRNhXE8bKxg0QdnrWl8hatk=; 7:MOtTlWoLaQ0Q3r0wN+IMdSlwAPCC3kmAeC7qJgKv0NVkzeqz2nOEFSgTeRZ86ldKdtUOu8x2JB4hzWA+6sl6jgcLAKDYAw4Uhl1keDCNR6ZwcRojjRj135D3FwqtO7kGRms0q+zqChmY4xG0LtTw4WobS9WWcYvJ6ydMp5ZAeFV1fsXNbcvL9TfsLCNwZtMLjQgLDYq2Cy/NCa8WHB21pqTAVTR4Up6FWF4tRWK2If5JU3ghEA7vzk+jC56O0ISI x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 15efdaa8-94cb-4a02-c585-08d548204d04 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008031)(2017052603307)(7153060); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820)(192374486261705)(788757137089)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0528942FD8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39860400002)(346002)(396003)(366004)(13464003)(51444003)(32952001)(199004)(55784002)(189003)(377424004)(53754006)(93886005)(81156014)(74316002)(81166006)(2501003)(8676002)(5660300001)(77096006)(316002)(230783001)(68736007)(478600001)(7736002)(229853002)(305945005)(2900100001)(3846002)(53546011)(6116002)(8936002)(2950100002)(6246003)(53946003)(80792005)(53936002)(2906002)(3660700001)(99286004)(25786009)(2201001)(55016002)(9686003)(6306002)(14454004)(66066001)(6506007)(33656002)(561944003)(76176011)(110136005)(3280700002)(59450400001)(97736004)(7696005)(345774005)(6436002)(4001150100001)(86362001)(966005)(105586002)(72206003)(106356001)(102836004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 15efdaa8-94cb-4a02-c585-08d548204d04 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2017 03:09:50.8448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6184> : inlines <6273> : streams <1773717> : uri <2554711> Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 03:10:21 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Wednesday, December 20, 2017 7:59 PM > To: mohamed.boucadair@orange.com; dots@ietf.org; > christian.jacquenet@orange.com > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > I think this would be helpful to implementers so that they know the > minimum of what should be supported. +1 -Tiru >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 20 December 2017 14:08 > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Re-, >=20 > Providing some guidance to implementers is helpful, IMO. >=20 > The ACL YANG module defines these features: > * l2-acl > * mixed-ipv4-acl > * mixed-ipv6-acl > * l2-l3-ipv4-ipv6-acl > * tcp-acl > * udp-acl > * icmp-acl > * any-acl > * interface-stats >=20 > We can indicate that in the context of DOTS, the following features MUST = be > supported: > * ipv4-acl > * ipv6-acl > * tcp-acl > * udp-acl > * icmp-acl >=20 > This branch of the module MUST NOT be implemented because we are not > touching interfaces: > +--rw interfaces >=20 > I would be silent about the other features. >=20 > We can discourage from using "reject" action. >=20 > I can draft some text among those lines, if needed. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:28 =C0=A0: BOUCADAIR Mohame= d > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: [Dots= ] > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > Good point. I have discussed with Tiru in the past about nominating a > > subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think > > is irrelevant), and it may sense to also have a "never to use" subset > list. > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 13:19 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > I'm hesitating to add "reject" in the context for DDoS because it will > > require sending ICMP messages to (misbehaving) sources. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR Moha= med > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > See inline [Jon1]. > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: -bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 12:56 > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR Mo= hamed > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > [Dots] > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Med, > > > > > > > > See inline [Jon] > > > > > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' > > > > should really be called 'acl-set-name' and 'acl-set-type' > > > > respectively in all the appropriate reference points. > > > > > > [Med] Please note that as per YANG naming conventions, there is > > > little value in repeating names in a given hierarchy. I'm sure this > > > will be a comment we will get from yangdoctors if we change the > > > names as you suggest. > > > [Jon1] Fair enough > > > > > > > > > > > > > > augment /ietf-acl:access-lists: > > > > +--rw dots-acl-order > > > > +--rw acl-set* [set-name type] > > > > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl-n= ame > > > > +--rw acl-set-type -> /ietf-acl:access-lists/acl/acl= - > > type > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 20 December 2017 11:58 > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > Subject: Re: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Jon, > > > > > > > > Thank you for the comments. > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAIR = Mohamed > > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > > [Dots] > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi Med, > > > > > > > > > > You need to update the following in the diff pdf > > > > > > > > > > 1. Introduction > > > > > > > > > > Replace > > > > > ... from these sites is protected from DDoS attacks. The DOTS > > > > > client uses the.... > > > > > with > > > > > ... from these sites is protected from DDoS attack mitigation. > > > > > The DOTS client uses the.... > > > > > > > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > > > [Jon] The context here is white-listed IPs - the whitelisted IPs > > > > should not get mitigated, not protected from DDoS attacks. So, 'yes= '. > > > > [Jon] I should have added in the rest of the line "The DOTS client > > > > uses the DOTS data channel to convey the white-listed IP prefixes > > > > of the partner sites to its DOTS server." > > > > > > > > > Otherwise > > > > > > > > > > 7.1 Install Filtering rules > > > > > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > > > Should this be added? > > > [Jon1] you have not responded to this question > > > > > > > > > > Replace > > > > > Content-Type: "application/yang+data+json" > > > > > With - should not have the quotes I believe (change is needed in > > > > > several > > > > > places) > > > > > Content-Type: application/yang+data+json > > > > > > > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > > > Replace > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > [RFC8040] > > > > > MAY be used to specify how a ACE is inserted within an ACL and > > > > > how > > a > > > > > ACL is inserted within an ACL list. > > > > > With - ACL Lists are not configured to be ordered > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > [RFC8040] > > > > > MAY be used to specify how a ACE is inserted within an ACL and > > > > > how > > a > > > > > ACL is inserted within an ACL Set in container dots-acl-order. > > > > > > > > > > > > > [Med] I made some minor changes to your proposal: > > > > > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY > > > > be > > used > > > > to specify how an Access Control Entry (ACE) is inserted within = an > > > > ACL and how an ACL is inserted within an ACL set in container do= ts- > > > > acl-order. > > > > [Jon] Works for me > > > > > > > > > As part of another discussion on the use of client-identifiers, > > > > > I am not happy with (it is too restrictive). The draft > > > > > elsewhere refers to the control of IPs being revealed > > > > > > > > > > In order to prevent leaking internal information outside a clie= nt- > > > > > domain, client-side DOTS gateways SHOULD NOT reveal the > > > > > identity > > of > > > > > internal DOTS clients (client-identifier) unless explicitly > > > > > configured to do so. > > > > > > > > > > > > > [Med] Is it too restrictive? > > > > > > > > It does set the bar where an administrator has to instruct the > > > > gateway explicitly about the information to be inserted/leaked. > > > > > > > > This text follows the reco in: https://tools.ietf.org/html/rfc8165 > > > > > > > > [Jon] This follows on from our other discussions about > > > > client-identifiers > > > > - > > > > which actually do not reveal the identity of the client (there is > > > > no IP information, the unique information about the client is one > > > > way hashed into the client-identifier). That said, the DOTS > > > > server can work out how many clients there actually are behind the > > > > gateway and which of them are more active, but I do not see this > > > > as a real security risk. All traffic is encrypted, making it > > > > difficult for any other device to work out what is going on. > > > > Without the client-identifier (or some alternative "mangling" > > > > of > > > > the mitigation ids to provide uniqueness) the DOTS server cannot > > > > effectively / correctly handle the same mitigation-id when > > > > requested /used by different DOTS clients. > > > > > > > > > > > > > > [Med] In order to keep this text (and its initial intent) aside from > > > the client-id discussion. I suggest to make this change: > > > > > > In order to prevent leaking internal information outside a client- > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity o= f > > > internal DOTS clients (e.g., source IP address) unless explicitly > > > configured to do so. > > > > > > We may update based on the conclusion of the client-id discussion. > > > > > > Hope this is OK with you. > > > [Jon1] Yes, this is a good initial move for me. > > > > > > Please double check at: > > > https://github.com/boucadair/IETF-Drafts- > > > Reviews/blob/master/wdiff%20draft-i > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > [Jon1] Apart from one thing above, you have captured this email threa= d. > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 20 December 2017 09:11 > > > > > To: dots@ietf.org > > > > > Cc: JACQUENET Christian IMT/OLN > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi all, > > > > > > > > > > Christian has kindly reviewed this version of the draft. Many > > > > > thanks to him. > > > > > > > > > > > > > > > Proposed changes are available at: > > > > > https://github.com/boucadair/IETF-Drafts- > > > > > Reviews/blob/master/wdiff%20draft-i > > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.p > > > > > df > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre 2= 017 > > > > > > 16:37 > > > =C0=A0: > > > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Re-, > > > > > > > > > > > > The main changes in this version are as follows: > > > > > > - Remove target-ip because it is redundant with target-prefix > > > > > > - Indicate that the order of establishing signal/data channel > > > > > > is implementation/deployment specific > > > > > > - Mention that the signal channel I-D is the authoritative > > > > > > reference for manipulating client-id; the data channel must > > > > > > follow the signal channel spec. > > > > > > - Add a discussion about translation implications > > > > > > - Add conflict support > > > > > > - The same resource can be associated with different aliases > > > > > > if multiple dots clients are deployed within a network > > > > > > - Check the normative language > > > > > > > > > > > > Please review and share comments. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre 20= 17 > > > > > > > 16:32 > > =C0=A0: > > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I= -D > > > Action: > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > Internet-Drafts directories. > > > > > > > This draft is a work item of the DDoS Open Threat Signaling > > > > > > > WG of the IETF. > > > > > > > > > > > > > > Title : Distributed Denial-of-Service Open > > > Threat > > > > > > > Signaling (DOTS) Data Channel > > > > > > > Authors : Tirumaleswar Reddy > > > > > > > Mohamed Boucadair > > > > > > > Kaname Nishizuka > > > > > > > Liang Xia > > > > > > > Prashanth Patil > > > > > > > Andrew Mortensen > > > > > > > Nik Teague > > > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > > > Pages : 31 > > > > > > > Date : 2017-12-18 > > > > > > > > > > > > > > Abstract: > > > > > > > The document specifies a Distributed Denial-of-Service > > > > > > > Open > > > > Threat > > > > > > > Signaling (DOTS) data channel used for bulk exchange of > > > > > > > data > > > not > > > > > > > easily or appropriately communicated through the DOTS > > > > > > > signal > > > > > channel > > > > > > > under attack conditions. > > > > > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > > > specification. > > > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > > > Please update these statements with the RFC number to be > > > > > > > assigned > > > > > to > > > > > > > this document: > > > > > > > > > > > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > > > Signaling > > > > > > > (DOTS) Data Channel"; > > > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channe > > > > > > > l/ > > > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-c > > > > > > > ha > > > > > > > nn > > > > > > > el > > > > > > > -1 > > > > > > > 1 > > > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-chan= n > > > > > > > el > > > > > > > -1 > > > > > > > 1 > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 00:10:54 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FF9129C56 for ; Thu, 21 Dec 2017 00:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLMD0_ERUD8p for ; Thu, 21 Dec 2017 00:10:50 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A545120227 for ; Thu, 21 Dec 2017 00:10:50 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 447E540F12; Thu, 21 Dec 2017 09:10:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 1B4A71C0109; Thu, 21 Dec 2017 09:10:48 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 09:10:43 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" , JACQUENET Christian IMT/OLN Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQHTeBYrfA5l02glEU6495oM3LXs4KNL9KUAgAASYwCAABxmgIAABvsAgAAJHgCAAAPPAIAAApaAgAACsACAAAsJAIAABgAAgADUXbCAAFOAwA== Date: Thu, 21 Dec 2017 08:10:43 +0000 Message-ID: References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> <052301d3799e$e8f3c5c0$badb5140$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 08:10:53 -0000 Hi all,=20 Please find below a text proposal to address the implementation note issue:= =20 =3D=3D DOTS implementations MUST support the following features defined in [I-D.ietf-netmod-acl-model]: match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match- on-icmp, ipv4, and ipv6. Given that DOTS data channel does not deal with interfaces, the support of the "ietf-interfaces" module [RFC7223] and its augmentation in the "ietf-access-control-list" module are not required for DOTS. Specifically, the support of interface-related features and branches (e.g., interface-attachment, interface-stats, acl-aggregate-stats, and interface-acl-aggregate) of the ACL YANG module is not required. The following forwarding actions MUST be supported: 'accept' and 'drop' The support of 'reject' action is NOT RECOMMENDED because it is not appropriate in the context of DDoS mitigation. Generating ICMP messages to notify drops when mitigating a DDoS attack will exacerbate the DDoS attack. Further, it will be used by an attacker as an explicit signal that the traffic is being blocked. =3D=3D Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: jeudi 21 d=E9cembre 2017 04:10 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET > Christian IMT/OLN > Objet=A0: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, December 20, 2017 7:59 PM > > To: mohamed.boucadair@orange.com; dots@ietf.org; > > christian.jacquenet@orange.com > > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > I think this would be helpful to implementers so that they know the > > minimum of what should be supported. >=20 > +1 >=20 > -Tiru >=20 > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 14:08 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > Providing some guidance to implementers is helpful, IMO. > > > > The ACL YANG module defines these features: > > * l2-acl > > * mixed-ipv4-acl > > * mixed-ipv6-acl > > * l2-l3-ipv4-ipv6-acl > > * tcp-acl > > * udp-acl > > * icmp-acl > > * any-acl > > * interface-stats > > > > We can indicate that in the context of DOTS, the following features MUS= T > be > > supported: > > * ipv4-acl > > * ipv6-acl > > * tcp-acl > > * udp-acl > > * icmp-acl > > > > This branch of the module MUST NOT be implemented because we are not > > touching interfaces: > > +--rw interfaces > > > > I would be silent about the other features. > > > > We can discourage from using "reject" action. > > > > I can draft some text among those lines, if needed. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:28 =C0=A0: BOUCADAIR Moha= med > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: [Do= ts] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > Good point. I have discussed with Tiru in the past about nominating = a > > > subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think > > > is irrelevant), and it may sense to also have a "never to use" subset > > list. > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 13:19 > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Re-, > > > > > > I'm hesitating to add "reject" in the context for DDoS because it wil= l > > > require sending ICMP messages to (misbehaving) sources. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR Mo= hamed > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > [Dots] > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Med, > > > > > > > > See inline [Jon1]. > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: -bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 20 December 2017 12:56 > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > Subject: Re: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAIR = Mohamed > > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > > [Dots] > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi Med, > > > > > > > > > > See inline [Jon] > > > > > > > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' > > > > > should really be called 'acl-set-name' and 'acl-set-type' > > > > > respectively in all the appropriate reference points. > > > > > > > > [Med] Please note that as per YANG naming conventions, there is > > > > little value in repeating names in a given hierarchy. I'm sure this > > > > will be a comment we will get from yangdoctors if we change the > > > > names as you suggest. > > > > [Jon1] Fair enough > > > > > > > > > > > > > > > > > > augment /ietf-acl:access-lists: > > > > > +--rw dots-acl-order > > > > > +--rw acl-set* [set-name type] > > > > > +--rw acl-set-name -> /ietf-acl:access-lists/acl/acl= - > name > > > > > +--rw acl-set-type -> /ietf-acl:access- > lists/acl/acl- > > > type > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 20 December 2017 11:58 > > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi Jon, > > > > > > > > > > Thank you for the comments. > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCADAI= R Mohamed > > > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: R= E: > > > > > > [Dots] > > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > You need to update the following in the diff pdf > > > > > > > > > > > > 1. Introduction > > > > > > > > > > > > Replace > > > > > > ... from these sites is protected from DDoS attacks. The DOTS > > > > > > client uses the.... > > > > > > with > > > > > > ... from these sites is protected from DDoS attack mitigation= . > > > > > > The DOTS client uses the.... > > > > > > > > > > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > > > > [Jon] The context here is white-listed IPs - the whitelisted IPs > > > > > should not get mitigated, not protected from DDoS attacks. So, > 'yes'. > > > > > [Jon] I should have added in the rest of the line "The DOTS clien= t > > > > > uses the DOTS data channel to convey the white-listed IP prefixe= s > > > > > of the partner sites to its DOTS server." > > > > > > > > > > > Otherwise > > > > > > > > > > > > 7.1 Install Filtering rules > > > > > > > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > > > > Should this be added? > > > > [Jon1] you have not responded to this question > > > > > > > > > > > > Replace > > > > > > Content-Type: "application/yang+data+json" > > > > > > With - should not have the quotes I believe (change is needed i= n > > > > > > several > > > > > > places) > > > > > > Content-Type: application/yang+data+json > > > > > > > > > > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > > > > > Replace > > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > > [RFC8040] > > > > > > MAY be used to specify how a ACE is inserted within an ACL an= d > > > > > > how > > > a > > > > > > ACL is inserted within an ACL list. > > > > > > With - ACL Lists are not configured to be ordered > > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > > [RFC8040] > > > > > > MAY be used to specify how a ACE is inserted within an ACL an= d > > > > > > how > > > a > > > > > > ACL is inserted within an ACL Set in container dots-acl-order= . > > > > > > > > > > > > > > > > [Med] I made some minor changes to your proposal: > > > > > > > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY > > > > > be > > > used > > > > > to specify how an Access Control Entry (ACE) is inserted withi= n > an > > > > > ACL and how an ACL is inserted within an ACL set in container > dots- > > > > > acl-order. > > > > > [Jon] Works for me > > > > > > > > > > > As part of another discussion on the use of client-identifiers, > > > > > > I am not happy with (it is too restrictive). The draft > > > > > > elsewhere refers to the control of IPs being revealed > > > > > > > > > > > > In order to prevent leaking internal information outside a > client- > > > > > > domain, client-side DOTS gateways SHOULD NOT reveal the > > > > > > identity > > > of > > > > > > internal DOTS clients (client-identifier) unless explicitly > > > > > > configured to do so. > > > > > > > > > > > > > > > > [Med] Is it too restrictive? > > > > > > > > > > It does set the bar where an administrator has to instruct the > > > > > gateway explicitly about the information to be inserted/leaked. > > > > > > > > > > This text follows the reco in: https://tools.ietf.org/html/rfc816= 5 > > > > > > > > > > [Jon] This follows on from our other discussions about > > > > > client-identifiers > > > > > - > > > > > which actually do not reveal the identity of the client (there is > > > > > no IP information, the unique information about the client is one > > > > > way hashed into the client-identifier). That said, the DOTS > > > > > server can work out how many clients there actually are behind th= e > > > > > gateway and which of them are more active, but I do not see this > > > > > as a real security risk. All traffic is encrypted, making it > > > > > difficult for any other device to work out what is going on. > > > > > Without the client-identifier (or some alternative "mangling" > > > > > of > > > > > the mitigation ids to provide uniqueness) the DOTS server cannot > > > > > effectively / correctly handle the same mitigation-id when > > > > > requested /used by different DOTS clients. > > > > > > > > > > > > > > > > > > [Med] In order to keep this text (and its initial intent) aside fro= m > > > > the client-id discussion. I suggest to make this change: > > > > > > > > In order to prevent leaking internal information outside a > client- > > > > domain, client-side DOTS gateways SHOULD NOT reveal the identity > of > > > > internal DOTS clients (e.g., source IP address) unless explicitl= y > > > > configured to do so. > > > > > > > > We may update based on the conclusion of the client-id discussion. > > > > > > > > Hope this is OK with you. > > > > [Jon1] Yes, this is a good initial move for me. > > > > > > > > Please double check at: > > > > https://github.com/boucadair/IETF-Drafts- > > > > Reviews/blob/master/wdiff%20draft-i > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf > > > > [Jon1] Apart from one thing above, you have captured this email > thread. > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 20 December 2017 09:11 > > > > > > To: dots@ietf.org > > > > > > Cc: JACQUENET Christian IMT/OLN > > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Christian has kindly reviewed this version of the draft. Many > > > > > > thanks to him. > > > > > > > > > > > > > > > > > > Proposed changes are available at: > > > > > > https://github.com/boucadair/IETF-Drafts- > > > > > > Reviews/blob/master/wdiff%20draft-i > > > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.= p > > > > > > df > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cembre= 2017 > > > > > > > 16:37 > > > > =C0=A0: > > > > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > The main changes in this version are as follows: > > > > > > > - Remove target-ip because it is redundant with target-prefix > > > > > > > - Indicate that the order of establishing signal/data channel > > > > > > > is implementation/deployment specific > > > > > > > - Mention that the signal channel I-D is the authoritative > > > > > > > reference for manipulating client-id; the data channel must > > > > > > > follow the signal channel spec. > > > > > > > - Add a discussion about translation implications > > > > > > > - Add conflict support > > > > > > > - The same resource can be associated with different aliases > > > > > > > if multiple dots clients are deployed within a network > > > > > > > - Check the normative language > > > > > > > > > > > > > > Please review and share comments. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > > > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembre = 2017 > > > > > > > > 16:32 > > > =C0=A0: > > > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots]= I-D > > > > Action: > > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > > Internet-Drafts directories. > > > > > > > > This draft is a work item of the DDoS Open Threat Signaling > > > > > > > > WG of the IETF. > > > > > > > > > > > > > > > > Title : Distributed Denial-of-Service Ope= n > > > > Threat > > > > > > > > Signaling (DOTS) Data Channel > > > > > > > > Authors : Tirumaleswar Reddy > > > > > > > > Mohamed Boucadair > > > > > > > > Kaname Nishizuka > > > > > > > > Liang Xia > > > > > > > > Prashanth Patil > > > > > > > > Andrew Mortensen > > > > > > > > Nik Teague > > > > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > > > > Pages : 31 > > > > > > > > Date : 2017-12-18 > > > > > > > > > > > > > > > > Abstract: > > > > > > > > The document specifies a Distributed Denial-of-Service > > > > > > > > Open > > > > > Threat > > > > > > > > Signaling (DOTS) data channel used for bulk exchange of > > > > > > > > data > > > > not > > > > > > > > easily or appropriately communicated through the DOTS > > > > > > > > signal > > > > > > channel > > > > > > > > under attack conditions. > > > > > > > > > > > > > > > > This is a companion document to the DOTS signal channel > > > > > > > > specification. > > > > > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > > > > > Please update these statements with the RFC number to be > > > > > > > > assigned > > > > > > to > > > > > > > > this document: > > > > > > > > > > > > > > > > o "This version of this YANG module is part of RFC > XXXX;" > > > > > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat > > > > Signaling > > > > > > > > (DOTS) Data Channel"; > > > > > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-chann= e > > > > > > > > l/ > > > > > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel-11 > > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-= c > > > > > > > > ha > > > > > > > > nn > > > > > > > > el > > > > > > > > -1 > > > > > > > > 1 > > > > > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-ch= ann > > > > > > > > el > > > > > > > > -1 > > > > > > > > 1 > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 00:46:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71900124207 for ; Thu, 21 Dec 2017 00:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcWnGFrWOtWs for ; Thu, 21 Dec 2017 00:46:48 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34931200FC for ; Thu, 21 Dec 2017 00:46:47 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRwV2-0006hc-Tg; Thu, 21 Dec 2017 08:46:45 +0000 From: "Jon Shallow" To: , , "Konda, Tirumaleswar Reddy" , References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> <052301d3799e$e8f3c5c0$badb5140$@jpshallow.com> In-Reply-To: Date: Thu, 21 Dec 2017 08:46:46 -0000 Message-ID: <059c01d37a38$3c2bd860$b4838920$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyQI0LseCAS4vHlUBRtT+lgIXfanwAliUIcgDNMrJHwIky9+qoekjvLA= Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 08:46:50 -0000 Hi Med, I think a copy of the YANG tree (including the MUST netmod-acl = information) for ietf-dots-data-channel should also be included (as well as leaving = the existing augment information) - so that it is easy to look at the final layout. Otherwise the additional text below looks fine. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 December 2017 08:11 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Hi all,=20 Please find below a text proposal to address the implementation note = issue:=20 =3D=3D DOTS implementations MUST support the following features defined in [I-D.ietf-netmod-acl-model]: match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match- on-icmp, ipv4, and ipv6. Given that DOTS data channel does not deal with interfaces, the support of the "ietf-interfaces" module [RFC7223] and its augmentation in the "ietf-access-control-list" module are not required for DOTS. Specifically, the support of interface-related features and branches (e.g., interface-attachment, interface-stats, acl-aggregate-stats, and interface-acl-aggregate) of the ACL YANG module is not required. The following forwarding actions MUST be supported: 'accept' and 'drop' The support of 'reject' action is NOT RECOMMENDED because it is not appropriate in the context of DDoS mitigation. Generating ICMP messages to notify drops when mitigating a DDoS attack will exacerbate the DDoS attack. Further, it will be used by an attacker as an explicit signal that the traffic is being blocked. =3D=3D Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > Tirumaleswar Reddy Envoy=E9=A0: jeudi 21 d=E9cembre 2017 04:10 =C0=A0: = Jon=20 > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian = > IMT/OLN Objet=A0: Re: [Dots] TR: I-D Action:=20 > draft-ietf-dots-data-channel-11.txt >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, December 20, 2017 7:59 PM > > To: mohamed.boucadair@orange.com; dots@ietf.org;=20 > > christian.jacquenet@orange.com > > Subject: Re: [Dots] TR: I-D Action:=20 > > draft-ietf-dots-data-channel-11.txt > > > > Hi Med, > > > > I think this would be helpful to implementers so that they know the=20 > > minimum of what should be supported. >=20 > +1 >=20 > -Tiru >=20 > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 20 December 2017 14:08 > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > Subject: Re: [Dots] TR: I-D Action:=20 > > draft-ietf-dots-data-channel-11.txt > > > > Re-, > > > > Providing some guidance to implementers is helpful, IMO. > > > > The ACL YANG module defines these features: > > * l2-acl > > * mixed-ipv4-acl > > * mixed-ipv6-acl > > * l2-l3-ipv4-ipv6-acl > > * tcp-acl > > * udp-acl > > * icmp-acl > > * any-acl > > * interface-stats > > > > We can indicate that in the context of DOTS, the following features=20 > > MUST > be > > supported: > > * ipv4-acl > > * ipv6-acl > > * tcp-acl > > * udp-acl > > * icmp-acl > > > > This branch of the module MUST NOT be implemented because we are not = > > touching interfaces: > > +--rw interfaces > > > > I would be silent about the other features. > > > > We can discourage from using "reject" action. > > > > I can draft some text among those lines, if needed. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:28 =C0=A0: BOUCADAIR = Mohamed=20 > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE:=20 > > > [Dots] > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > Good point. I have discussed with Tiru in the past about=20 > > > nominating a subset of netmod-acl that DOTS has to support (e.g.=20 > > > L2 stuff I think is irrelevant), and it may sense to also have a=20 > > > "never to use" subset > > list. > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 13:19 > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Re-, > > > > > > I'm hesitating to add "reject" in the context for DDoS because it=20 > > > will require sending ICMP messages to (misbehaving) sources. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR = Mohamed=20 > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: = RE: > > > > [Dots] > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Med, > > > > > > > > See inline [Jon1]. > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: -bounces@ietf.org] On Behalf Of=20 > > > > mohamed.boucadair@orange.com > > > > Sent: 20 December 2017 12:56 > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > Subject: Re: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: = BOUCADAIR Mohamed=20 > > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: = RE: > > > > > [Dots] > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi Med, > > > > > > > > > > See inline [Jon] > > > > > > > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' > > > > > should really be called 'acl-set-name' and 'acl-set-type' > > > > > respectively in all the appropriate reference points. > > > > > > > > [Med] Please note that as per YANG naming conventions, there is=20 > > > > little value in repeating names in a given hierarchy. I'm sure=20 > > > > this will be a comment we will get from yangdoctors if we change = > > > > the names as you suggest. > > > > [Jon1] Fair enough > > > > > > > > > > > > > > > > > > augment /ietf-acl:access-lists: > > > > > +--rw dots-acl-order > > > > > +--rw acl-set* [set-name type] > > > > > +--rw acl-set-name -> = /ietf-acl:access-lists/acl/acl- > name > > > > > +--rw acl-set-type -> /ietf-acl:access- > lists/acl/acl- > > > type > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > > mohamed.boucadair@orange.com > > > > > Sent: 20 December 2017 11:58 > > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi Jon, > > > > > > > > > > Thank you for the comments. > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: = BOUCADAIR=20 > > > > > > Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > > > [Dots] > > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > You need to update the following in the diff pdf > > > > > > > > > > > > 1. Introduction > > > > > > > > > > > > Replace > > > > > > ... from these sites is protected from DDoS attacks. The=20 > > > > > > DOTS client uses the.... > > > > > > with > > > > > > ... from these sites is protected from DDoS attack = mitigation. > > > > > > The DOTS client uses the.... > > > > > > > > > > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > > > > [Jon] The context here is white-listed IPs - the whitelisted=20 > > > > > IPs should not get mitigated, not protected from DDoS attacks. = > > > > > So, > 'yes'. > > > > > [Jon] I should have added in the rest of the line "The DOTS=20 > > > > > client uses the DOTS data channel to convey the white-listed=20 > > > > > IP prefixes of the partner sites to its DOTS server." > > > > > > > > > > > Otherwise > > > > > > > > > > > > 7.1 Install Filtering rules > > > > > > > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for = actions. > > > > > > Should this be added? > > > > [Jon1] you have not responded to this question > > > > > > > > > > > > Replace > > > > > > Content-Type: "application/yang+data+json" > > > > > > With - should not have the quotes I believe (change is=20 > > > > > > needed in several > > > > > > places) > > > > > > Content-Type: application/yang+data+json > > > > > > > > > > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > > > > > Replace > > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > > [RFC8040] > > > > > > MAY be used to specify how a ACE is inserted within an ACL = > > > > > > and how > > > a > > > > > > ACL is inserted within an ACL list. > > > > > > With - ACL Lists are not configured to be ordered > > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > > [RFC8040] > > > > > > MAY be used to specify how a ACE is inserted within an ACL = > > > > > > and how > > > a > > > > > > ACL is inserted within an ACL Set in container = dots-acl-order. > > > > > > > > > > > > > > > > [Med] I made some minor changes to your proposal: > > > > > > > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040])=20 > > > > > MAY be > > > used > > > > > to specify how an Access Control Entry (ACE) is inserted=20 > > > > > within > an > > > > > ACL and how an ACL is inserted within an ACL set in=20 > > > > > container > dots- > > > > > acl-order. > > > > > [Jon] Works for me > > > > > > > > > > > As part of another discussion on the use of=20 > > > > > > client-identifiers, I am not happy with (it is too=20 > > > > > > restrictive). The draft elsewhere refers to the control of=20 > > > > > > IPs being revealed > > > > > > > > > > > > In order to prevent leaking internal information outside a > client- > > > > > > domain, client-side DOTS gateways SHOULD NOT reveal the=20 > > > > > > identity > > > of > > > > > > internal DOTS clients (client-identifier) unless = explicitly > > > > > > configured to do so. > > > > > > > > > > > > > > > > [Med] Is it too restrictive? > > > > > > > > > > It does set the bar where an administrator has to instruct the = > > > > > gateway explicitly about the information to be = inserted/leaked. > > > > > > > > > > This text follows the reco in:=20 > > > > > https://tools.ietf.org/html/rfc8165 > > > > > > > > > > [Jon] This follows on from our other discussions about=20 > > > > > client-identifiers > > > > > - > > > > > which actually do not reveal the identity of the client (there = > > > > > is no IP information, the unique information about the client=20 > > > > > is one way hashed into the client-identifier). That said, the = > > > > > DOTS server can work out how many clients there actually are=20 > > > > > behind the gateway and which of them are more active, but I do = > > > > > not see this as a real security risk. All traffic is=20 > > > > > encrypted, making it difficult for any other device to work = out what is going on. > > > > > Without the client-identifier (or some alternative "mangling" > > > > > of > > > > > the mitigation ids to provide uniqueness) the DOTS server=20 > > > > > cannot effectively / correctly handle the same mitigation-id=20 > > > > > when requested /used by different DOTS clients. > > > > > > > > > > > > > > > > > > [Med] In order to keep this text (and its initial intent) aside=20 > > > > from the client-id discussion. I suggest to make this change: > > > > > > > > In order to prevent leaking internal information outside a > client- > > > > domain, client-side DOTS gateways SHOULD NOT reveal the=20 > > > > identity > of > > > > internal DOTS clients (e.g., source IP address) unless = explicitly > > > > configured to do so. > > > > > > > > We may update based on the conclusion of the client-id = discussion. > > > > > > > > Hope this is OK with you. > > > > [Jon1] Yes, this is a good initial move for me. > > > > > > > > Please double check at: > > > > https://github.com/boucadair/IETF-Drafts- > > > > Reviews/blob/master/wdiff%20draft-i > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.p > > > > df [Jon1] Apart from one thing above, you have captured this=20 > > > > email > thread. > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 20 December 2017 09:11 > > > > > > To: dots@ietf.org > > > > > > Cc: JACQUENET Christian IMT/OLN > > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Christian has kindly reviewed this version of the draft.=20 > > > > > > Many thanks to him. > > > > > > > > > > > > > > > > > > Proposed changes are available at: > > > > > > https://github.com/boucadair/IETF-Drafts- > > > > > > Reviews/blob/master/wdiff%20draft-i > > > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel- > > > > > > 12.p > > > > > > df > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > [mailto:dots-bounces@ietf.org] De la part de=20 > > > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 = d=E9cembre=20 > > > > > > > 2017 > > > > > > > 16:37 > > > > =C0=A0: > > > > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > The main changes in this version are as follows: > > > > > > > - Remove target-ip because it is redundant with=20 > > > > > > > target-prefix > > > > > > > - Indicate that the order of establishing signal/data=20 > > > > > > > channel is implementation/deployment specific > > > > > > > - Mention that the signal channel I-D is the authoritative = > > > > > > > reference for manipulating client-id; the data channel=20 > > > > > > > must follow the signal channel spec. > > > > > > > - Add a discussion about translation implications > > > > > > > - Add conflict support > > > > > > > - The same resource can be associated with different=20 > > > > > > > aliases if multiple dots clients are deployed within a=20 > > > > > > > network > > > > > > > - Check the normative language > > > > > > > > > > > > > > Please review and share comments. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de > > > > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 = d=E9cembre=20 > > > > > > > > 2017 > > > > > > > > 16:32 > > > =C0=A0: > > > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: = [Dots]=20 > > > > > > > > I-D > > > > Action: > > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > > > > > > > Internet-Drafts directories. > > > > > > > > This draft is a work item of the DDoS Open Threat=20 > > > > > > > > Signaling WG of the IETF. > > > > > > > > > > > > > > > > Title : Distributed Denial-of-Service = Open > > > > Threat > > > > > > > > Signaling (DOTS) Data Channel > > > > > > > > Authors : Tirumaleswar Reddy > > > > > > > > Mohamed Boucadair > > > > > > > > Kaname Nishizuka > > > > > > > > Liang Xia > > > > > > > > Prashanth Patil > > > > > > > > Andrew Mortensen > > > > > > > > Nik Teague > > > > > > > > Filename : draft-ietf-dots-data-channel-11.txt > > > > > > > > Pages : 31 > > > > > > > > Date : 2017-12-18 > > > > > > > > > > > > > > > > Abstract: > > > > > > > > The document specifies a Distributed=20 > > > > > > > > Denial-of-Service Open > > > > > Threat > > > > > > > > Signaling (DOTS) data channel used for bulk exchange=20 > > > > > > > > of data > > > > not > > > > > > > > easily or appropriately communicated through the DOTS = > > > > > > > > signal > > > > > > channel > > > > > > > > under attack conditions. > > > > > > > > > > > > > > > > This is a companion document to the DOTS signal = channel > > > > > > > > specification. > > > > > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > > > > > Please update these statements with the RFC number to = > > > > > > > > be assigned > > > > > > to > > > > > > > > this document: > > > > > > > > > > > > > > > > o "This version of this YANG module is part of RFC > XXXX;" > > > > > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open=20 > > > > > > > > Threat > > > > Signaling > > > > > > > > (DOTS) Data Channel"; > > > > > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-ch > > > > > > > > anne > > > > > > > > l/ > > > > > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel > > > > > > > > -11=20 > > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-da > > > > > > > > ta-c > > > > > > > > ha > > > > > > > > nn > > > > > > > > el > > > > > > > > -1 > > > > > > > > 1 > > > > > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-c > > > > > > > > hann > > > > > > > > el > > > > > > > > -1 > > > > > > > > 1 > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from=20 > > > > > > > > the time of submission until the htmlized version and=20 > > > > > > > > diff are available at tools.ietf.org. > > > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 01:16:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE241200FC for ; Thu, 21 Dec 2017 01:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOKA4G4Kkz0f for ; Thu, 21 Dec 2017 01:16:13 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C33126CF9 for ; Thu, 21 Dec 2017 01:16:13 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id A54D6A0ECA; Thu, 21 Dec 2017 10:16:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 7D0331A01C6; Thu, 21 Dec 2017 10:16:11 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 10:16:06 +0100 From: To: Jon Shallow , "dots@ietf.org" , "Konda, Tirumaleswar Reddy" , "JACQUENET Christian IMT/OLN" Thread-Topic: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt Thread-Index: AQIbqPWItCjae2nZGU7jVxS6UVkdlAJVOsQfAafcD40CuHdijAHP0sstAcNUbVoBw44YyQI0LseCAS4vHlUBRtT+lgIXfanwAliUIcgDNMrJHwIky9+qoekjvLCAAAlu4A== Date: Thu, 21 Dec 2017 09:16:06 +0000 Message-ID: References: <151361109473.3491.4119944658869204153@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09A314@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1838f93f-e7ab-4245-8aad-c1e4ec355c21@OPEXCLILM44.corporate.adroot.infra.ftgroup> <04f801d3797b$9a7b3360$cf719a20$@jpshallow.com> <050c01d3798d$4b21eae0$e165c0a0$@jpshallow.com> <6449a771-75f6-4770-8350-231f56c4e8a4@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <051101d37993$c1d21380$45763a80$@jpshallow.com> <0637f78a-eb71-4b92-89fe-1f9f90173f5e@OPEXCLILM31.corporate.adroot.infra.ftgroup> <051e01d37996$64dc4990$2e94dcb0$@jpshallow.com> <21a0776e-0d37-4804-94b7-7d97275c9c46@OPEXCLILM6D.corporate.adroot.infra.ftgroup> <052301d3799e$e8f3c5c0$badb5140$@jpshallow.com> <059c01d37a38$3c2bd860$b4838920$@jpshallow.com> In-Reply-To: <059c01d37a38$3c2bd860$b4838920$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 09:16:17 -0000 Re-, Happily.=20 Please check at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/mast= er/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-ietf-dots-data-chann= el-12.pdf=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > Envoy=E9=A0: jeudi 21 d=E9cembre 2017 09:47 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; Konda, Tirumaleswar Red= dy; > JACQUENET Christian IMT/OLN > Objet=A0: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi Med, >=20 > I think a copy of the YANG tree (including the MUST netmod-acl > information) > for ietf-dots-data-channel should also be included (as well as leaving th= e > existing augment information) - so that it is easy to look at the final > layout. Otherwise the additional text below looks fine. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 21 December 2017 08:11 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org; JACQUENET > Christian IMT/OLN > Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt >=20 > Hi all, >=20 > Please find below a text proposal to address the implementation note > issue: >=20 > =3D=3D > DOTS implementations MUST support the following features defined in > [I-D.ietf-netmod-acl-model]: >=20 > match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match- > on-icmp, ipv4, and ipv6. >=20 > Given that DOTS data channel does not deal with interfaces, the > support of the "ietf-interfaces" module [RFC7223] and its > augmentation in the "ietf-access-control-list" module are not > required for DOTS. Specifically, the support of interface-related > features and branches (e.g., interface-attachment, interface-stats, > acl-aggregate-stats, and interface-acl-aggregate) of the ACL YANG > module is not required. >=20 > The following forwarding actions MUST be supported: >=20 > 'accept' and 'drop' >=20 > The support of 'reject' action is NOT RECOMMENDED because it is not > appropriate in the context of DDoS mitigation. Generating ICMP > messages to notify drops when mitigating a DDoS attack will > exacerbate the DDoS attack. Further, it will be used by an attacker > as an explicit signal that the traffic is being blocked. > =3D=3D >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: jeudi 21 d=E9cembre 2017 04:10 =C0=A0: = Jon > > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian > > IMT/OLN Objet=A0: Re: [Dots] TR: I-D Action: > > draft-ietf-dots-data-channel-11.txt > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Wednesday, December 20, 2017 7:59 PM > > > To: mohamed.boucadair@orange.com; dots@ietf.org; > > > christian.jacquenet@orange.com > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Hi Med, > > > > > > I think this would be helpful to implementers so that they know the > > > minimum of what should be supported. > > > > +1 > > > > -Tiru > > > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 20 December 2017 14:08 > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > Subject: Re: [Dots] TR: I-D Action: > > > draft-ietf-dots-data-channel-11.txt > > > > > > Re-, > > > > > > Providing some guidance to implementers is helpful, IMO. > > > > > > The ACL YANG module defines these features: > > > * l2-acl > > > * mixed-ipv4-acl > > > * mixed-ipv6-acl > > > * l2-l3-ipv4-ipv6-acl > > > * tcp-acl > > > * udp-acl > > > * icmp-acl > > > * any-acl > > > * interface-stats > > > > > > We can indicate that in the context of DOTS, the following features > > > MUST > > be > > > supported: > > > * ipv4-acl > > > * ipv6-acl > > > * tcp-acl > > > * udp-acl > > > * icmp-acl > > > > > > This branch of the module MUST NOT be implemented because we are not > > > touching interfaces: > > > +--rw interfaces > > > > > > I would be silent about the other features. > > > > > > We can discourage from using "reject" action. > > > > > > I can draft some text among those lines, if needed. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:28 =C0=A0: BOUCADAIR Mo= hamed > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > [Dots] > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > Hi Med, > > > > > > > > Good point. I have discussed with Tiru in the past about > > > > nominating a subset of netmod-acl that DOTS has to support (e.g. > > > > L2 stuff I think is irrelevant), and it may sense to also have a > > > > "never to use" subset > > > list. > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 20 December 2017 13:19 > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > Subject: Re: [Dots] TR: I-D Action: > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > Re-, > > > > > > > > I'm hesitating to add "reject" in the context for DDoS because it > > > > will require sending ICMP messages to (misbehaving) sources. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 14:09 =C0=A0: BOUCADAIR = Mohamed > > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: RE: > > > > > [Dots] > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Hi Med, > > > > > > > > > > See inline [Jon1]. > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: -bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 20 December 2017 12:56 > > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > Re-, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 13:23 =C0=A0: BOUCADAI= R Mohamed > > > > > > IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN Objet=A0: R= E: > > > > > > [Dots] > > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > In addition, I think that 'set-name' and 'type' in 'acl-set' > > > > > > should really be called 'acl-set-name' and 'acl-set-type' > > > > > > respectively in all the appropriate reference points. > > > > > > > > > > [Med] Please note that as per YANG naming conventions, there is > > > > > little value in repeating names in a given hierarchy. I'm sure > > > > > this will be a comment we will get from yangdoctors if we change > > > > > the names as you suggest. > > > > > [Jon1] Fair enough > > > > > > > > > > > > > > > > > > > > > > augment /ietf-acl:access-lists: > > > > > > +--rw dots-acl-order > > > > > > +--rw acl-set* [set-name type] > > > > > > +--rw acl-set-name -> /ietf-acl:access- > lists/acl/acl- > > name > > > > > > +--rw acl-set-type -> /ietf-acl:access- > > lists/acl/acl- > > > > type > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 20 December 2017 11:58 > > > > > > To: Jon Shallow; dots@ietf.org; JACQUENET Christian IMT/OLN > > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > Thank you for the comments. > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 11:17 =C0=A0: BOUCAD= AIR > > > > > > > Mohamed IMT/OLN; dots@ietf.org; JACQUENET Christian IMT/OLN > Objet=A0: RE: > > > > > > > [Dots] > > > > > > > TR: I-D Action: draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > You need to update the following in the diff pdf > > > > > > > > > > > > > > 1. Introduction > > > > > > > > > > > > > > Replace > > > > > > > ... from these sites is protected from DDoS attacks. The > > > > > > > DOTS client uses the.... > > > > > > > with > > > > > > > ... from these sites is protected from DDoS attack > mitigation. > > > > > > > The DOTS client uses the.... > > > > > > > > > > > > > > > > > > > [Med] Do you really mean "protect..." from "...mitigation"? > > > > > > [Jon] The context here is white-listed IPs - the whitelisted > > > > > > IPs should not get mitigated, not protected from DDoS attacks. > > > > > > So, > > 'yes'. > > > > > > [Jon] I should have added in the rest of the line "The DOTS > > > > > > client uses the DOTS data channel to convey the white-listed > > > > > > IP prefixes of the partner sites to its DOTS server." > > > > > > > > > > > > > Otherwise > > > > > > > > > > > > > > 7.1 Install Filtering rules > > > > > > > > > > > > > > I-D.ietf-netmod-acl-model also supports 'reject' for actions. > > > > > > > Should this be added? > > > > > [Jon1] you have not responded to this question > > > > > > > > > > > > > > Replace > > > > > > > Content-Type: "application/yang+data+json" > > > > > > > With - should not have the quotes I believe (change is > > > > > > > needed in several > > > > > > > places) > > > > > > > Content-Type: application/yang+data+json > > > > > > > > > > > > > > > > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > > > > > > > Replace > > > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > > > [RFC8040] > > > > > > > MAY be used to specify how a ACE is inserted within an ACL > > > > > > > and how > > > > a > > > > > > > ACL is inserted within an ACL list. > > > > > > > With - ACL Lists are not configured to be ordered > > > > > > > The "insert" query parameter discussed in Section 4.8.5 of > > > > [RFC8040] > > > > > > > MAY be used to specify how a ACE is inserted within an ACL > > > > > > > and how > > > > a > > > > > > > ACL is inserted within an ACL Set in container dots-acl- > order. > > > > > > > > > > > > > > > > > > > [Med] I made some minor changes to your proposal: > > > > > > > > > > > > The "insert" query parameter (Section 4.8.5 of [RFC8040]) > > > > > > MAY be > > > > used > > > > > > to specify how an Access Control Entry (ACE) is inserted > > > > > > within > > an > > > > > > ACL and how an ACL is inserted within an ACL set in > > > > > > container > > dots- > > > > > > acl-order. > > > > > > [Jon] Works for me > > > > > > > > > > > > > As part of another discussion on the use of > > > > > > > client-identifiers, I am not happy with (it is too > > > > > > > restrictive). The draft elsewhere refers to the control of > > > > > > > IPs being revealed > > > > > > > > > > > > > > In order to prevent leaking internal information outside a > > client- > > > > > > > domain, client-side DOTS gateways SHOULD NOT reveal the > > > > > > > identity > > > > of > > > > > > > internal DOTS clients (client-identifier) unless explicitly > > > > > > > configured to do so. > > > > > > > > > > > > > > > > > > > [Med] Is it too restrictive? > > > > > > > > > > > > It does set the bar where an administrator has to instruct the > > > > > > gateway explicitly about the information to be inserted/leaked. > > > > > > > > > > > > This text follows the reco in: > > > > > > https://tools.ietf.org/html/rfc8165 > > > > > > > > > > > > [Jon] This follows on from our other discussions about > > > > > > client-identifiers > > > > > > - > > > > > > which actually do not reveal the identity of the client (there > > > > > > is no IP information, the unique information about the client > > > > > > is one way hashed into the client-identifier). That said, the > > > > > > DOTS server can work out how many clients there actually are > > > > > > behind the gateway and which of them are more active, but I do > > > > > > not see this as a real security risk. All traffic is > > > > > > encrypted, making it difficult for any other device to work out > what is going on. > > > > > > Without the client-identifier (or some alternative "mangling" > > > > > > of > > > > > > the mitigation ids to provide uniqueness) the DOTS server > > > > > > cannot effectively / correctly handle the same mitigation-id > > > > > > when requested /used by different DOTS clients. > > > > > > > > > > > > > > > > > > > > > > [Med] In order to keep this text (and its initial intent) aside > > > > > from the client-id discussion. I suggest to make this change: > > > > > > > > > > In order to prevent leaking internal information outside a > > client- > > > > > domain, client-side DOTS gateways SHOULD NOT reveal the > > > > > identity > > of > > > > > internal DOTS clients (e.g., source IP address) unless > explicitly > > > > > configured to do so. > > > > > > > > > > We may update based on the conclusion of the client-id discussion= . > > > > > > > > > > Hope this is OK with you. > > > > > [Jon1] Yes, this is a good initial move for me. > > > > > > > > > > Please double check at: > > > > > https://github.com/boucadair/IETF-Drafts- > > > > > Reviews/blob/master/wdiff%20draft-i > > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.p > > > > > df [Jon1] Apart from one thing above, you have captured this > > > > > email > > thread. > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 20 December 2017 09:11 > > > > > > > To: dots@ietf.org > > > > > > > Cc: JACQUENET Christian IMT/OLN > > > > > > > Subject: Re: [Dots] TR: I-D Action: > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > Christian has kindly reviewed this version of the draft. > > > > > > > Many thanks to him. > > > > > > > > > > > > > > > > > > > > > Proposed changes are available at: > > > > > > > https://github.com/boucadair/IETF-Drafts- > > > > > > > Reviews/blob/master/wdiff%20draft-i > > > > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel- > > > > > > > 12.p > > > > > > > df > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de > > > > > > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 18 d=E9cemb= re > > > > > > > > 2017 > > > > > > > > 16:37 > > > > > =C0=A0: > > > > > > > > dots@ietf.org Objet=A0: [Dots] TR: I-D Action: > > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > The main changes in this version are as follows: > > > > > > > > - Remove target-ip because it is redundant with > > > > > > > > target-prefix > > > > > > > > - Indicate that the order of establishing signal/data > > > > > > > > channel is implementation/deployment specific > > > > > > > > - Mention that the signal channel I-D is the authoritative > > > > > > > > reference for manipulating client-id; the data channel > > > > > > > > must follow the signal channel spec. > > > > > > > > - Add a discussion about translation implications > > > > > > > > - Add conflict support > > > > > > > > - The same resource can be associated with different > > > > > > > > aliases if multiple dots clients are deployed within a > > > > > > > > network > > > > > > > > - Check the normative language > > > > > > > > > > > > > > > > Please review and share comments. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de > > > > > > > > > internet- drafts@ietf.org Envoy=E9=A0: lundi 18 d=E9cembr= e > > > > > > > > > 2017 > > > > > > > > > 16:32 > > > > =C0=A0: > > > > > > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dot= s] > > > > > > > > > I-D > > > > > Action: > > > > > > > > > draft-ietf-dots-data-channel-11.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > > > Internet-Drafts directories. > > > > > > > > > This draft is a work item of the DDoS Open Threat > > > > > > > > > Signaling WG of the IETF. > > > > > > > > > > > > > > > > > > Title : Distributed Denial-of-Service > Open > > > > > Threat > > > > > > > > > Signaling (DOTS) Data Channel > > > > > > > > > Authors : Tirumaleswar Reddy > > > > > > > > > Mohamed Boucadair > > > > > > > > > Kaname Nishizuka > > > > > > > > > Liang Xia > > > > > > > > > Prashanth Patil > > > > > > > > > Andrew Mortensen > > > > > > > > > Nik Teague > > > > > > > > > Filename : > draft-ietf-dots-data-channel-11.txt > > > > > > > > > Pages : 31 > > > > > > > > > Date : 2017-12-18 > > > > > > > > > > > > > > > > > > Abstract: > > > > > > > > > The document specifies a Distributed > > > > > > > > > Denial-of-Service Open > > > > > > Threat > > > > > > > > > Signaling (DOTS) data channel used for bulk exchange > > > > > > > > > of data > > > > > not > > > > > > > > > easily or appropriately communicated through the DOTS > > > > > > > > > signal > > > > > > > channel > > > > > > > > > under attack conditions. > > > > > > > > > > > > > > > > > > This is a companion document to the DOTS signal channe= l > > > > > > > > > specification. > > > > > > > > > > > > > > > > > > Editorial Note (To be removed by RFC Editor) > > > > > > > > > > > > > > > > > > Please update these statements with the RFC number to > > > > > > > > > be assigned > > > > > > > to > > > > > > > > > this document: > > > > > > > > > > > > > > > > > > o "This version of this YANG module is part of RFC > > XXXX;" > > > > > > > > > > > > > > > > > > o "RFC XXXX: Distributed Denial-of-Service Open > > > > > > > > > Threat > > > > > Signaling > > > > > > > > > (DOTS) Data Channel"; > > > > > > > > > > > > > > > > > > o reference: RFC XXXX > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-ch > > > > > > > > > anne > > > > > > > > > l/ > > > > > > > > > > > > > > > > > > There are also htmlized versions available at: > > > > > > > > > https://tools.ietf.org/html/draft-ietf-dots-data-channel > > > > > > > > > -11 > > > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-da > > > > > > > > > ta-c > > > > > > > > > ha > > > > > > > > > nn > > > > > > > > > el > > > > > > > > > -1 > > > > > > > > > 1 > > > > > > > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-= c > > > > > > > > > hann > > > > > > > > > el > > > > > > > > > -1 > > > > > > > > > 1 > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 01:48:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2B512D7EE for ; Thu, 21 Dec 2017 01:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrZou9ENpO79 for ; Thu, 21 Dec 2017 01:48:04 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A41312D77B for ; Thu, 21 Dec 2017 01:48:04 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 28CACC0880 for ; Thu, 21 Dec 2017 10:48:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 0D48840074 for ; Thu, 21 Dec 2017 10:48:03 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 10:48:02 +0100 From: To: "dots@ietf.org" Thread-Topic: DATA Channel: Filtering Lifetime Thread-Index: AdN6QMhuu4yNaHSDQRGxvfzspSLSRw== Date: Thu, 21 Dec 2017 09:48:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09BE21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A09BE21OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] DATA Channel: Filtering Lifetime X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 09:48:07 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A09BE21OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I suggest to add a lifetime attribute to the ACL entry so that we avoid sta= le rules be maintained by the server indefinitely. The change would look li= ke: augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw lifetime? int32 Motivation: This will be a first guard, for example, to soften maintaining stale entrie= s when a network renumbers but forgot to update/delete old filtering rules. ACLs are today enforced by an administrator (operator) for its own usages. = He/she can modify them based on local criteria. Scripts are usually used to= delete/add/etc. The game changes with DOTS as the rules are instructed by = a third party. The mitigation provider may end with a long list if stale en= tries because DOTS clients didn't cleared...which is undesirable. Of course= , a mitigation server provider may accept filtering rules with indefinite l= ifetime; this is deployment-specific. Lifetime is an information to be maintained at the DOTS server level, not a= t the device level. Network devices do not require to support the lifetime.= Clearing invalid entries will be managed through the DOTS server. The text will indicate that a DOTS server MUST NOT clear an expired entry w= hen an attack mitigation is ongoing. Any objection to this change? Opinions about the recommended value are also welcome. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A09BE21OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I suggest to add a lifetime attribute to th= e ACL entry so that we avoid stale rules be maintained by the server indefi= nitely. The change would look like:

 

  augment /iet= f-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    = +--rw lifetime?   int32

 

Motivation:

 

This will be a first guard, for example, to= soften maintaining stale entries when a network renumbers but forgot to up= date/delete old filtering rules.

 

ACLs are today enforced by an administrator= (operator) for its own usages. He/she can modify them based on local crite= ria. Scripts are usually used to delete/add/etc. The game changes with DOTS as the rules are instructed by a third party. T= he mitigation provider may end with a long list if stale entries because DO= TS clients didn’t cleared…which is undesirable. Of course, a mi= tigation server provider may accept filtering rules with indefinite lifetime; this is deployment-specific.

 

Life= time is an information to be maintained at the DOTS server level, not at th= e device level. Network devices do not require to support the lifetime. Clearing invalid entries will be managed through the= DOTS server.

 

The text will indicate that a DOTS server M= UST NOT clear an expired entry when an attack mitigation is ongoing.

 

Any = objection to this change?

 

Opin= ions about the recommended value are also welcome.

 

Chee= rs,

Med<= o:p>

 

 

 

 

 

 

 

--_000_787AE7BB302AE849A7480A190F8B93300A09BE21OPEXCLILMA3corp_-- From nobody Thu Dec 21 06:05:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AF812D878 for ; Thu, 21 Dec 2017 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfesUgbY3YGH for ; Thu, 21 Dec 2017 06:05:24 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D8F12D877 for ; Thu, 21 Dec 2017 06:05:24 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eS1TO-0006s9-Ge; Thu, 21 Dec 2017 14:05:22 +0000 From: "Jon Shallow" To: , References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 21 Dec 2017 14:05:23 -0000 Message-ID: <05e001d37a64$bec4c080$3c4e4180$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQDAx+IWL3o/zjUSLKzuNis+SDZ2JgDl0/WwpWkC51A= Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 14:05:36 -0000 Hi Med, Comments in my first pass through the -14 version 3. Design Overview "in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. ." Second trailing period not needed. 4.4.1. Request Mitigation "Attributes with emty values" should read " Attributes with empty = values" 4.5 DOTS Channel Session Configuration Replace If distinct configuration are used, DOTS agents MUST follow the appropriate configuration set as a with (plural) If distinct configurations are used, DOTS agents MUST follow the appropriate configuration set as a 4.5.2 Convey DOTS Signal Channel Session Configuration I think config-interval should be defined in seconds - to be consistent = with lifetime, heartbeat-interval etc. Replace If a non-null value of 'config-interval' is received by a DOTS agent, it has to issue a PUT request to refresh the configuration with If a non-zero value of 'config-interval' is received by a DOTS client, it has to issue a PUT request to refresh the configuration Replace (peace-time may now be idle-config, and attack-time-config may = now be mitigating-config) peace-time-config: Set of configuration parameters to use during peacetime. This attribute has the same structure as 'attack-time- config'. With idle-config: Set of configuration parameters to use during peacetime. This attribute has the same structure as 'mitigating- config'. If this parameter is not defined, then the peacetime configuration 'idle-config' is assumed to be the same as 'mitigating-config'. Figure 18: config-interval should have a current-value Should Figure 19 include config-interval ? 5.1 Tree structure Should=20 | | +--ro acl-name -> /ietf-acl:access-lists/acl/acl-name | | +--ro acl-type -> /ietf-acl:access-lists/acl/acl-type Be (data channel definition is OK - other than perhaps 'set-name' really should be name', and 'type' should be 'type' due to netmod-acl potential changes) | | +--ro acl-name -> /ietf-dots-data-channel:access-lists/acl/name | | +--ro acl-type -> / ietf-dots-data-channel:access-lists/acl/type 'config-interval' also needs a current/min/max -value setting (as you = have in Figure 17) unless the DOTS server is going to control this = absolutely. Figure 18 will need updating as well. yang:zero-based-counter64 is not supported by JSON (a JavaScript = limitation as I understand it) RFC7159 6. Numbers=20 Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. 5.2 YANG module ack-random-factor was a float - and so current-value etc. subtypes of ack-random-factor should be floats, not int16. I suggest that we use a different name - i.e. current-value-decimal. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 December 2017 15:35 To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Re-, This version integrates the outcomes of the mailing list discussion, in particular: - Multiple client-id values does not mean anymore that multiple GWs have injected a value each.=20 - Introduce attack-time-config and peace-time-config - Add some text to suggest dots servers to send heartbeats immediately = after receiving the one from the peer dots client.=20 - Refreshing the configuration must not occur during attack times.=20 The document is still using client-side and server-side DOTS GW terms. = The text will be aligned with the requirements I-D. Jon, please double check.=20 All, please review and share your comments. Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet-=20 > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0:=20 > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action:=20 > draft-ietf-dots-signal-channel-14.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the=20 > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-14.txt > Pages : 84 > Date : 2017-12-19 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned = to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > 4 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 06:06:50 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACF2127078 for ; Thu, 21 Dec 2017 06:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFPW2aVLvvXp for ; Thu, 21 Dec 2017 06:06:46 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8A7127337 for ; Thu, 21 Dec 2017 06:06:45 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 86B54160B98 for ; Thu, 21 Dec 2017 15:06:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 6DE1218006A for ; Thu, 21 Dec 2017 15:06:44 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 15:06:44 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTeNzce1SBtvp2XUqJiA0/nltgO6NKzAeAgAACeTCAAAUgMIAAA+FQgAD7FCCAABWNgIAB7Hbw Date: Thu, 21 Dec 2017 14:06:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09C0DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09AE7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A09B2C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 14:06:48 -0000 Hi all,=20 Tiru, Jon, and I organized a conf-call to discuss this issue. We agreed on = the following: * Introduce 'request-nonce' that will be used to prevent collisions. This p= arameter must be inserted by a DOTS client in all its requests and echoed b= y the server. It is valid for both signal and data channels. * client-identifier will be renamed to reflect its actual usage: supply inf= ormation about the client domain to the ultimate DOTS server for policy enf= orcement. It has nothing to do anymore with collisions detect.=20 * As in -14, only server-side gateways are allowed to inject client-identif= ier.=20 Unless there are objections, the draft will be updated accordingly.=20 FWIW, you may find some information in slides 9/10/11/12/13 of the material= available at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master= /DOTS%20Gateways-client%20identifier%20discussion.pdf=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: mercredi 20 d=E9cembre 2017 10:07 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Wednesday, December 20, 2017 12:59 PM > > To: Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > Tiru, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 17:51 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots]= I-D > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Tuesday, December 19, 2017 9:44 PM > > > > To: Konda, Tirumaleswar Reddy > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] I-D Action: > > > > draft-ietf-dots-signal-channel-14.txt > > > > > > > > Hi Tiru, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:55 =C0=A0: BOUCADAIR Moh= amed > > > > > IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] I-D > > > > > Action: draft-ietf-dots-signal-channel-14.txt > > > > > > > > > > I don't think the DOTS signal channel draft should enhance the > > > > > functionality of DOTS gateway to aggregate mitigation requests, > > > > > it's not discussed in any of the requirements and architecture > drafts. > > > > > > > > [Med] IMO, it is out of the scope of the document to recommend or > > > > preclude this. > > > > > > Agreed. > > > > > > > > Why cannot the client-identifier be generated by client-side DOTS > > > > > gateway (I don't understand the privacy problem, if the > > > > > client-identifier does not reveal the actual DOTS client identity= ) > ? > > > > > > > > [Med] because, e.g., "DOTS server can fully trust the server-side > > > gateway > > > > but cannot fully trust the client-side gateway". > > > > > > Yes, but client-identifier can also be used to detect and resolve > > > collision (e.g. two DOTS clients using the same alias-name). How wil= l > > > collisions be handled with this change ? > > > > > > > [Med] The question is whether we need to handle this as a bug or > feature: > > e.g., > > * DOTS clients, which belong to the same domain, using the same alias > can be > > handled as part of conflict management and be reported by the final > server > > as such. > > * The client-side DOTS gateway may be instructed to detect locally > > collision/conflicts and notify the responsible clients locally. > Collisions are not > > leaked to the server domain. >=20 > Please look into 3.1.8 and 3.2.2 in dots use cases spec, there could be > hundreds of DOTS clients and it does not look like a good approach to kee= p > rejecting requests just because they had the same alias-name. We discusse= d > this problem in the mailing list before agreeing to use the client- > identifier as a list to resolve collisions (see > https://mailarchive.ietf.org/arch/msg/dots/qqJ_aV8zDuwCP84qtJEmP-oIRKA). >=20 > -Tiru From nobody Thu Dec 21 06:54:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75FC12D878 for ; Thu, 21 Dec 2017 06:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtbgpA_YE2Ov for ; Thu, 21 Dec 2017 06:54:54 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE18120724 for ; Thu, 21 Dec 2017 06:54:54 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 5466FC0B72; Thu, 21 Dec 2017 15:54:40 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 2FCA6C0083; Thu, 21 Dec 2017 15:54:40 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 15:54:39 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQDAx+IWe1SBtvp2XUqJiA0/nltgOwDl0/WwpWkC51CAAwiv0A== Date: Thu, 21 Dec 2017 14:54:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A09C160@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05e001d37a64$bec4c080$3c4e4180$@jpshallow.com> In-Reply-To: <05e001d37a64$bec4c080$3c4e4180$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 14:54:57 -0000 Re-, Thank you for the review.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 21 d=E9cembre 2017 15:05 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Med, >=20 > Comments in my first pass through the -14 version >=20 > 3. Design Overview >=20 > "in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. ." >=20 > Second trailing period not needed. [Med] Already fixed in my local copy. Thanks.=20 >=20 > 4.4.1. Request Mitigation >=20 > "Attributes with emty values" should read " Attributes with empty values" [Med] Idem as above.=20 >=20 > 4.5 DOTS Channel Session Configuration >=20 > Replace >=20 > If distinct configuration are > used, DOTS agents MUST follow the appropriate configuration set as a >=20 > with (plural) >=20 > If distinct configurations are > used, DOTS agents MUST follow the appropriate configuration set as a >=20 [Med] Fixed. =20 >=20 > 4.5.2 Convey DOTS Signal Channel Session Configuration >=20 > I think config-interval should be defined in seconds - to be consistent > with > lifetime, heartbeat-interval etc. [Med] Works for me. =20 >=20 > Replace >=20 > If a non-null value of 'config-interval' is received by a DOTS > agent, it has to issue a PUT request to refresh the configuration >=20 > with >=20 > If a non-zero value of 'config-interval' is received by a DOTS > client, it has to issue a PUT request to refresh the configuration >=20 [Med] OK. > Replace (peace-time may now be idle-config, and attack-time-config may no= w > be mitigating-config) >=20 > peace-time-config: Set of configuration parameters to use during > peacetime. This attribute has the same structure as 'attack-time- > config'. >=20 > With >=20 > idle-config: Set of configuration parameters to use during > peacetime. This attribute has the same structure as 'mitigating- > config'. If this parameter is not defined, then the peacetime > configuration 'idle-config' is assumed to be the same as > 'mitigating-config'. >=20 [Med] We do already have a default behavior: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. This means that the default values will be used if not specified.=20 If the same config is to be used for both idle-mitigation, both should be r= eturned.=20 Actually, this is what I meant in this discussion: =3D=3D [Jon] A minor comment - is the following more logical and more descriptive= ? [Med] I considered this but favored the other one because it is more compac= t. For example, when the same config is to be used for both peace/attack ti= mes, you just need to omit "peace-time-config", while you need to include t= he same value twice for the other proposal. Do you have a strong preference= ? =3D=3D=3D=3D =20 > Figure 18: config-interval should have a current-value >=20 > Should Figure 19 include config-interval ? [Med] This is on purpose to indicate that config-interval can be omitted. >=20 > 5.1 Tree structure >=20 > Should >=20 > | | +--ro acl-name -> > /ietf-acl:access-lists/acl/acl-name > | | +--ro acl-type -> > /ietf-acl:access-lists/acl/acl-type >=20 > Be (data channel definition is OK - other than perhaps 'set-name' really > should be name', and 'type' should be 'type' due to netmod-acl potential > changes) >=20 > | | +--ro acl-name -> > /ietf-dots-data-channel:access-lists/acl/name > | | +--ro acl-type -> / > ietf-dots-data-channel:access-lists/acl/type >=20 [Med] No, the initial one is correct.=20 > 'config-interval' also needs a current/min/max -value setting (as you hav= e > in Figure 17) unless the DOTS server is going to control this absolutely. > Figure 18 will need updating as well. [Med] Good catch. Figure 17 is wrong.=20 There is no value for having this for config-interval, because it is always= up to the server to decide which value to put.=20 I will update figures 17/18 accordingly.=20 >=20 > yang:zero-based-counter64 is not supported by JSON (a JavaScript > limitation > as I understand it) > RFC7159 6. Numbers > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. [Med] I guess we need to encode them as strings. RFC7493#section-2.2 says t= he following:=20 An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. >=20 > 5.2 YANG module >=20 > ack-random-factor was a float - and so current-value etc. subtypes of > ack-random-factor should be floats, not int16. I suggest that we use a > different name - i.e. current-value-decimal. >=20 [Med] I guess you are referring to section 6.=20 =20 It seems that we will need *-value for major type 7. > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 19 December 2017 15:35 > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Re-, >=20 > This version integrates the outcomes of the mailing list discussion, in > particular: > - Multiple client-id values does not mean anymore that multiple GWs have > injected a value each. > - Introduce attack-time-config and peace-time-config > - Add some text to suggest dots servers to send heartbeats immediately > after > receiving the one from the peer dots client. > - Refreshing the configuration must not occur during attack times. >=20 > The document is still using client-side and server-side DOTS GW terms. Th= e > text will be aligned with the requirements I-D. >=20 > Jon, please double check. >=20 > All, please review and share your comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0: > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Action: > > draft-ietf-dots-signal-channel-14.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the > > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-14.txt > > Pages : 84 > > Date : 2017-12-19 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > o This RFC > > > > Please update TBD statements with the port number to be assigned to > > DOTS Signal Channel Protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > > 4 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 08:15:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E81252BA for ; Thu, 21 Dec 2017 08:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_hGgGgYCgKi for ; Thu, 21 Dec 2017 08:15:54 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782AF126CD8 for ; Thu, 21 Dec 2017 08:15:54 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eS3Ve-0006wh-Ta; Thu, 21 Dec 2017 16:15:51 +0000 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93300A09BE21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09BE21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 21 Dec 2017 16:15:52 -0000 Message-ID: <05fc01d37a76$f8d080e0$ea7182a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FD_01D37A76.F8D080E0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHI8ce6aBcw0ieOAMgV8dXqRX48daNjB9DQ Archived-At: Subject: Re: [Dots] DATA Channel: Filtering Lifetime X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:15:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05FD_01D37A76.F8D080E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med, Instead of doing this at the ace level (of which there could be many per filter definition), I would prefer this to be done at the dots-acl-order + acl-set level, or at the acl level. I think the lifetime needs to be sufficiently long to prevent frequent refreshes, but not too long that stale entries never get flushed. A day feels too small, a week feels about right and a month is too long. Otherwise, this makes sense to me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 December 2017 09:48 To: dots@ietf.org Subject: [Dots] DATA Channel: Filtering Lifetime Hi all, I suggest to add a lifetime attribute to the ACL entry so that we avoid stale rules be maintained by the server indefinitely. The change would look like: augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw lifetime? int32 Motivation: This will be a first guard, for example, to soften maintaining stale entries when a network renumbers but forgot to update/delete old filtering rules. ACLs are today enforced by an administrator (operator) for its own usages. He/she can modify them based on local criteria. Scripts are usually used to delete/add/etc. The game changes with DOTS as the rules are instructed by a third party. The mitigation provider may end with a long list if stale entries because DOTS clients didn't cleared.which is undesirable. Of course, a mitigation server provider may accept filtering rules with indefinite lifetime; this is deployment-specific. Lifetime is an information to be maintained at the DOTS server level, not at the device level. Network devices do not require to support the lifetime. Clearing invalid entries will be managed through the DOTS server. The text will indicate that a DOTS server MUST NOT clear an expired entry when an attack mitigation is ongoing. Any objection to this change? Opinions about the recommended value are also welcome. Cheers, Med ------=_NextPart_000_05FD_01D37A76.F8D080E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Instead of doing this at = the ace level (of which there could be many per filter definition), I = would prefer this to be done at the dots-acl-order + acl-set level, or = at the acl level.

 

I think the lifetime = needs to be sufficiently long to prevent frequent refreshes, but not too = long that stale entries never get flushed.  A day feels too small, = a week feels about right and a month is too = long.

 

Otherwise, this makes = sense to me.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 21 December 2017 = 09:48
To: dots@ietf.org
Subject: [Dots] DATA = Channel: Filtering Lifetime

 

Hi all,

 

I suggest to add a lifetime attribute to the ACL entry so = that we avoid stale rules be maintained by the server indefinitely. The = change would look like:

 

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw = lifetime?   int32

 

Motivation:

 

This will be a first guard, for example, to soften = maintaining stale entries when a network renumbers but forgot to = update/delete old filtering rules.

 

ACLs are today enforced by an administrator (operator) for = its own usages. He/she can modify them based on local criteria. Scripts = are usually used to delete/add/etc. The game changes with DOTS as the = rules are instructed by a third party. The mitigation provider may end = with a long list if stale entries because DOTS clients didn’t = cleared…which is undesirable. Of course, a mitigation server = provider may accept filtering rules with indefinite lifetime; this is = deployment-specific.

 

Lifetime is an = information to be maintained at the DOTS server level, not at the device = level. Network devices do not require to support the lifetime. Clearing = invalid entries will be managed through the DOTS server. =

 

The text = will indicate that a DOTS server MUST NOT clear an expired entry when an = attack mitigation is ongoing.

 

Any objection to = this change?

 

Opinions about the = recommended value are also welcome.

 

Cheers,

Med

 

 

 

 

 

 

 

 

------=_NextPart_000_05FD_01D37A76.F8D080E0-- From nobody Thu Dec 21 08:49:11 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D9A12D958 for ; Thu, 21 Dec 2017 08:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaWUFcLBfcxb for ; Thu, 21 Dec 2017 08:49:05 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B18312D94F for ; Thu, 21 Dec 2017 08:49:05 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eS41n-0006y0-ST; Thu, 21 Dec 2017 16:49:03 +0000 From: "Jon Shallow" To: , References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05e001d37a64$bec4c080$3c4e4180$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09C160@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09C160@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 21 Dec 2017 16:49:05 -0000 Message-ID: <061e01d37a7b$9cb303a0$d6190ae0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQDAx+IWL3o/zjUSLKzuNis+SDZ2JgDl0/WwAY8iFjgA0Y+5z6VZK6og Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:49:09 -0000 Hi Med, See inline [Jon]. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 December 2017 14:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Re-, Thank you for the review.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 21 d=E9cembre 2017 15:05 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] = I-D=20 > Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Med, >=20 > Comments in my first pass through the -14 version >=20 > 3. Design Overview >=20 > "in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. = ." >=20 > Second trailing period not needed. [Med] Already fixed in my local copy. Thanks.=20 >=20 > 4.4.1. Request Mitigation >=20 > "Attributes with emty values" should read " Attributes with empty = values" [Med] Idem as above.=20 >=20 > 4.5 DOTS Channel Session Configuration >=20 > Replace >=20 > If distinct configuration are > used, DOTS agents MUST follow the appropriate configuration set as=20 > a >=20 > with (plural) >=20 > If distinct configurations are > used, DOTS agents MUST follow the appropriate configuration set as=20 > a >=20 [Med] Fixed. =20 >=20 > 4.5.2 Convey DOTS Signal Channel Session Configuration >=20 > I think config-interval should be defined in seconds - to be=20 > consistent with lifetime, heartbeat-interval etc. [Med] Works for me. =20 >=20 > Replace >=20 > If a non-null value of 'config-interval' is received by a DOTS > agent, it has to issue a PUT request to refresh the=20 > configuration >=20 > with >=20 > If a non-zero value of 'config-interval' is received by a DOTS > client, it has to issue a PUT request to refresh the=20 > configuration >=20 [Med] OK. [Jon] Not yet updated > Replace (peace-time may now be idle-config, and attack-time-config may = > now be mitigating-config) >=20 > peace-time-config: Set of configuration parameters to use during > peacetime. This attribute has the same structure as = 'attack-time- > config'. >=20 > With >=20 > idle-config: Set of configuration parameters to use during > peacetime. This attribute has the same structure as = 'mitigating- > config'. If this parameter is not defined, then the peacetime=20 > configuration 'idle-config' is assumed to be the same as=20 > 'mitigating-config'. >=20 [Med] We do already have a default behavior: The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters. This means that the default values will be used if not specified.=20 If the same config is to be used for both idle-mitigation, both should = be returned.=20 Actually, this is what I meant in this discussion: =3D=3D [Jon] A minor comment - is the following more logical and more = descriptive? [Med] I considered this but favored the other one because it is more compact. For example, when the same config is to be used for both peace/attack times, you just need to omit "peace-time-config", while you need to include the same value twice for the other proposal. Do you have = a strong preference? =3D=3D=3D=3D [Jon] OK - having both is fine by me - and if something is not defined = then it takes on the default values. =20 > Figure 18: config-interval should have a current-value >=20 > Should Figure 19 include config-interval ? [Med] This is on purpose to indicate that config-interval can be = omitted. [Jon] OK >=20 > 5.1 Tree structure >=20 > Should >=20 > | | +--ro acl-name -> > /ietf-acl:access-lists/acl/acl-name > | | +--ro acl-type -> > /ietf-acl:access-lists/acl/acl-type >=20 > Be (data channel definition is OK - other than perhaps 'set-name'=20 > really should be name', and 'type' should be 'type' due to netmod-acl=20 > potential > changes) >=20 > | | +--ro acl-name -> > /ietf-dots-data-channel:access-lists/acl/name > | | +--ro acl-type -> / > ietf-dots-data-channel:access-lists/acl/type >=20 [Med] No, the initial one is correct.=20 [Jon] OK > 'config-interval' also needs a current/min/max -value setting (as you=20 > have in Figure 17) unless the DOTS server is going to control this absolutely. > Figure 18 will need updating as well. [Med] Good catch. Figure 17 is wrong.=20 There is no value for having this for config-interval, because it is = always up to the server to decide which value to put.=20 I will update figures 17/18 accordingly. [Jon] You currently have in your local copy draft config-interval only = for PUT, not GET, so config-interval is not under the control of the server. =20 >=20 > yang:zero-based-counter64 is not supported by JSON (a JavaScript=20 > limitation as I understand it) > RFC7159 6. Numbers > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. [Med] I guess we need to encode them as strings. RFC7493#section-2.2 = says the following:=20 An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. [Jon] Oh - yuk - this means that there will be bloat in the COAP packet = in the 5 places where int64 (or uint64) are used. [Jon] In all cases, I think that decimal64 will give us sufficient precision, as well as handle the numbers getting very large (e.g. bytes dropped). [Jon] If we do go with the string version, then there has to be extra = logic (and context knowledge) to convert any JSON into 64bit numbers to do any math on. >=20 > 5.2 YANG module >=20 > ack-random-factor was a float - and so current-value etc. subtypes of=20 > ack-random-factor should be floats, not int16. I suggest that we use = > a different name - i.e. current-value-decimal. >=20 [Med] I guess you are referring to section 6.=20 =20 It seems that we will need *-value for major type 7. [Jon] Correct - I see that you have updated this in your local copy = draft. > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 19 December 2017 15:35 > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Re-, >=20 > This version integrates the outcomes of the mailing list discussion,=20 > in > particular: > - Multiple client-id values does not mean anymore that multiple GWs=20 > have injected a value each. > - Introduce attack-time-config and peace-time-config > - Add some text to suggest dots servers to send heartbeats immediately = > after receiving the one from the peer dots client. > - Refreshing the configuration must not occur during attack times. >=20 > The document is still using client-side and server-side DOTS GW terms. = > The text will be aligned with the requirements I-D. >=20 > Jon, please double check. >=20 > All, please review and share your comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet-=20 > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0: > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action: > > draft-ietf-dots-signal-channel-14.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of=20 > > the IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-14.txt > > Pages : 84 > > Date : 2017-12-19 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and = configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned = to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > o This RFC > > > > Please update TBD statements with the port number to be assigned = to > > DOTS Signal Channel Protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel > > -1 > > 4 > > > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at=20 > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 20:24:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49C126C89 for ; Thu, 21 Dec 2017 20:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzyWYRDcqHwf for ; Thu, 21 Dec 2017 20:24:04 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6221200F1 for ; Thu, 21 Dec 2017 20:24:03 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 043B225F691; Fri, 22 Dec 2017 13:24:01 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id ACD8876343E; Fri, 22 Dec 2017 13:24:00 +0900 (JST) To: Jon Shallow , 'Jon Shallow' , mohamed.boucadair@orange.com, dots@ietf.org References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> <787AE7BB302AE849A7480A190F8B93300A09AA83@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <041901d378c1$1d219e00$5764da00$@jpshallow.com> <04f001d3797a$8eda5280$ac8ef780$@jpshallow.com> From: kaname nishizuka Message-ID: <93a8790e-7533-b246-c391-1692bbd8d5ee@nttv6.jp> Date: Fri, 22 Dec 2017 13:23:59 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <04f001d3797a$8eda5280$ac8ef780$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 04:24:07 -0000 I've carefully read the thread of " client-identifier: Recurisve signaling & Aggregation". I'm convinced of the advantage of the proposed terminology. It makes the function of the DOTS gateway clearer. It is worth to change and beneficial to the implementers and the new-readers. regards, Kaname On 2017/12/20 19:09, Jon Shallow wrote: > Hi WG > > Thinking about this overnight, I think I prefer > > "Client-Side DOTS Gateway" changed to "Client-Domain DOTS gateway" > "Server-Side DOTS Gateway" changed to "Server-Domain DOTS gateway" > "DOTS gateway server-side" changed to "DOTS gateway server-facing-side" > "DOTS gateway client-side" changed to "DOTS gateway client-facing-side" > > In all the appropriate documents. > > The reason for the latter two (taking the first one as an example) is that > "DOTS gateway server-facing-side" under the hood is the DOTS client > component of the DOTS gateway. "server-side" - does it refer to the DOTS > server component side of the DOTS gateway, or is it the side of the DOTS > gateway that talks to a DOTS server? > > Comments welcome to move forward on this one. > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: 19 December 2017 12:02 > To: mohamed.boucadair@orange.com; rdd@cert.org; dots@ietf.org > Subject: Re: [Dots] WGLC on DOTS Requirements > > Hi Roman and others, > > What triggered these term change requests was the difference in > interpretation of the word "side". > > 'Ahh – the light bulb has gone off – why our discussions had a disconnect. > It is down to the interpretation of the word “side†as used in “Client Side > DOTS gatewayâ€. To you (i.e. Med) it meant “control or ownershipâ€, to me > (i.e. Jon) “connectivity or position relative to DOTS gatewayâ€' > > It actually is recorded in > https://www.ietf.org/mail-archive/web/dots/current/msg01767.html > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 19 December 2017 10:16 > To: Roman Danyliw; dots@ietf.org > Subject: Re: [Dots] WGLC on DOTS Requirements > > Re-, > > I'm extracting this comment from Jon to be handled as part of the WGLC > comments: > > ============== > Jon said: > > To prevent others getting confused, my suggestion would be to update the > following in the various draft specs > > "Client-Side DOTS Gateway" to "Client Domain Managed DOTS gateway" > "Server-Side DOTS Gateway" to "Server Domain Managed DOTS gateway" > "DOTS gateway server-side" to "DOTS gateway server-facing-side" > "DOTS gateway client-side" to "DOTS gateway client-facing-side" > > The latter 2 should be defined somewhere. > ================ > > Please refer to: > https://www.ietf.org/mail-archive/web/dots/current/msg01765.html. > > I like the initial wording, but it seems this is not clear enough and may > lead to confusion. > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw >> Envoyé : jeudi 7 décembre 2017 21:51 À : dots@ietf.org Objet : [Dots] >> WGLC on DOTS Requirements >> >> Hello! >> >> Consistent with our discussion at the Singapore meeting and with the >> concurrence of the draft authors, we are starting a working group last >> call (WGLC) for the DOTS Requirements draft: >> >> Distributed Denial of Service (DDoS) Open Threat Signaling >> Requirements >> draft-ietf-dots-requirements-08 >> https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >> >> Please send all comments to the DOTS mailing list. >> >> This WGLC will end on January 2, 2018 (~3 weeks to account for >> end-of-the- calendar year vacations). >> >> Thanks, >> Roman >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 21 20:35:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0501200F1 for ; Thu, 21 Dec 2017 20:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02-k3GjgCFQG for ; Thu, 21 Dec 2017 20:35:10 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7112711D for ; Thu, 21 Dec 2017 20:35:09 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id ECA7A25F691; Fri, 22 Dec 2017 13:35:07 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id B938376343E; Fri, 22 Dec 2017 13:35:07 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <76fa8956-d96b-f900-9125-86e5644895c2@nttv6.jp> Date: Fri, 22 Dec 2017 13:35:07 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 04:35:14 -0000 small nits in the CBOR mapping example were found: 4.4.1.  Request Mitigation Figure 7: PUT for DOTS signal (CBOR) line 4: client identifier  18 20                             # unsigned(32)  it must be:  18 24                             # unsigned(36) line 13: target-prefix      04                          # unsigned(4)  it must be:     18 23                       # unsigned(35) regards, Kaname On 2017/12/20 0:34, mohamed.boucadair@orange.com wrote: > Re-, > > This version integrates the outcomes of the mailing list discussion, in particular: > - Multiple client-id values does not mean anymore that multiple GWs have injected a value each. > - Introduce attack-time-config and peace-time-config > - Add some text to suggest dots servers to send heartbeats immediately after receiving the one from the peer dots client. > - Refreshing the configuration must not occur during attack times. > > The document is still using client-side and server-side DOTS GW terms. The text will be aligned with the requirements I-D. > > Jon, please double check. > > All, please review and share your comments. > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de internet- >> drafts@ietf.org >> Envoyé : mardi 19 décembre 2017 16:19 >> À : i-d-announce@ietf.org >> Cc : dots@ietf.org >> Objet : [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DDoS Open Threat Signaling WG of the >> IETF. >> >> Title : Distributed Denial-of-Service Open Threat >> Signaling (DOTS) Signal Channel >> Authors : Tirumaleswar Reddy >> Mohamed Boucadair >> Prashanth Patil >> Andrew Mortensen >> Nik Teague >> Filename : draft-ietf-dots-signal-channel-14.txt >> Pages : 84 >> Date : 2017-12-19 >> >> Abstract: >> This document specifies the DOTS signal channel, a protocol for >> signaling the need for protection against Distributed Denial-of- >> Service (DDoS) attacks to a server capable of enabling network >> traffic mitigation on behalf of the requesting client. >> >> A companion document defines the DOTS data channel, a separate >> reliable communication layer for DOTS management and configuration >> purposes. >> >> Editorial Note (To be removed by RFC Editor) >> >> Please update these statements with the RFC number to be assigned to >> this document: >> >> o "This version of this YANG module is part of RFC XXXX;" >> >> o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Signal Channel"; >> >> o "| 3.00 | Alternate server | [RFCXXXX] |" >> >> o reference: RFC XXXX >> >> o This RFC >> >> Please update TBD statements with the port number to be assigned to >> DOTS Signal Channel Protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14 >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-14 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-14 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 22 01:22:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64611243F6 for ; Fri, 22 Dec 2017 01:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0Itx-eeXGY2 for ; Fri, 22 Dec 2017 01:22:37 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2944C1205F0 for ; Fri, 22 Dec 2017 01:22:37 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eSJXG-0007YT-Kl for ietf-supjps-dots@ietf.org; Fri, 22 Dec 2017 09:22:34 +0000 From: "Jon Shallow" To: Date: Fri, 22 Dec 2017 09:22:36 -0000 Message-ID: <06a901d37b06$681bf800$3853e800$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06AA_01D37B06.681BF800" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshw== Archived-At: Subject: [Dots] DOTS gateway loop handling X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 09:22:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06AA_01D37B06.681BF800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways, if there is a mis-configuration a request can end up getting bounced between a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechanism similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get added into both the signal and data channels. Regards Jon ------=_NextPart_000_06AA_01D37B06.681BF800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

While there never should be a loop in DOTS traffic = going via DOTS gateways, if there is a mis-configuration a request can = end up getting bounced between a set of (not necessarily adjacent) DOTS = gateways.

 

We need to make sure that this loop is broken – = possibly by using a mechanism similar to TTL in IP = packets.

 

If we agree that loops need to get broken, this = “feature” needs to get added into both the signal and data = channels.

 

Regards

 

Jon

------=_NextPart_000_06AA_01D37B06.681BF800-- From nobody Fri Dec 22 02:24:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9EB126DEE for ; Fri, 22 Dec 2017 02:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lwDkUQM8V6c for ; Fri, 22 Dec 2017 02:24:11 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812DC124239 for ; Fri, 22 Dec 2017 02:24:11 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513938250; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7 b/pgTEOaIS/ee50FZkVp9YWnMqMn3ht/fMApUaxG8 c=; b=os3hhY6NSAbeSzh7ZGT21qEeOQjjAAOqcJXiT0XbGSA6 A7H39FA+0A3p83ozNUUQgH/4lqDuLty05bW4U8bJXCweqWV1Zd 2Al3G9ycOONRLyQBBxLN5Bawp6KYy3lAugQAhP3oxO0Bn6TskM iHv6JFf5FFeDvpiqyae3A7QyMRA= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 7593_41f8_45b2f1b4_4ca0_4114_a221_87a677484c2c; Fri, 22 Dec 2017 04:24:09 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Dec 2017 05:24:08 -0500 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Dec 2017 05:24:07 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 22 Dec 2017 05:24:07 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Dec 2017 05:24:04 -0500 Received: from BN6PR16MB1777.namprd16.prod.outlook.com (10.172.28.141) by BN6PR16MB1779.namprd16.prod.outlook.com (10.172.28.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Fri, 22 Dec 2017 10:24:03 +0000 Received: from BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) by BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) with mapi id 15.20.0345.013; Fri, 22 Dec 2017 10:24:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7w Date: Fri, 22 Dec 2017 10:24:03 +0000 Message-ID: References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> In-Reply-To: <06a901d37b06$681bf800$3853e800$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1779; 6:f2BU1ybwiiD+L16Q0m0dE8swZUs/OPfryt99dcfpiPjZCZTV8mfy+HnP2Py5lTrYAe50x3nLWMzaDtuQmcY4oNrhRPvdKGK8H3x4VHXWqy3XRz+clvDvjP6e9sUQ8UlSfyEjk1H6agn7MaKuSVSnoW0t+XU2heJQD7XWUt9dMHtK0+sfmYeoMSQhu91nTjSpClhbc6HJ9gKbHM86v765GF5Y1Mit8HAF2emv70YEF5JGjW8oOWf7RBtVijDy8bcJbqpv3avaN9zLgQObTRVxClhWA8XzR5YoFOx4KsrCqrxzzala6eEn8deCIBBAW/gHzFs8A9daETfB5emJrij83f59HtphweSkZwtKdENl6Qw=; 5:PjIV0rN81WUiUfDpVkY6RR3TZS3q0Vd7EXXTUsKVAPECcdnzWDc1nWwRBKmjOPIjtaaOd/AMfsnkr88bbysIPhwAaAfTueo1oa+rSqDopPwOU4hBu8xc5cS5BsqXQOMfIELYmPOrsLPIkhYJwspuvmjL2y88zEMBKEet1ctETlc=; 24:5ixsVcFfNfkOu5j0j/bGI0TrOTooXLcwZR+RNGjEdDLipVIDO5qUOYQJcnEQXYkMefdcgY/kCsIkRj0ML/R7Erw29a8YV68tJh9dldM1ahk=; 7:r/EZPxKbG8n4qPVnasoqJ2FvUXpSwxeaUD+3pXTzRcxbaxDSZNHzSp62ItITFpskuNR/gsn9zvHA4A1+qHPIeqF4bgQ0GqEIGTQb12Uu1Fa+7WU7bMrIs1g+TWSliMFJEUmndAGWNxqxwdUItuSNgb+gS8ztouITn27a3O8fQBjFFxMyxS/l8xhwwVOWUBaQRaRpy+yCjRp7tQqeUc5XtAnihOiNo2/LU1UbPHrQEWiY1O3sYObRY+7VdKUe8jpH x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3dfb733f-5d42-480d-2a33-08d549261fce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008031)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:BN6PR16MB1779; x-ms-traffictypediagnostic: BN6PR16MB1779: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(3231023)(93006095)(93001095)(3002001)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB1779; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR16MB1779; x-forefront-prvs: 05299D545B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(189003)(199004)(32952001)(106356001)(72206003)(316002)(80792005)(97736004)(105586002)(6436002)(66066001)(229853002)(33656002)(77096006)(25786009)(7736002)(5660300001)(110136005)(9686003)(236005)(54896002)(6306002)(6506007)(14454004)(53546011)(2900100001)(81156014)(81166006)(86362001)(3280700002)(6246003)(2950100002)(59450400001)(478600001)(74316002)(76176011)(2501003)(606006)(99286004)(8936002)(966005)(53936002)(2906002)(102836004)(3660700001)(68736007)(6116002)(3846002)(8676002)(19609705001)(790700001)(55016002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1779; H:BN6PR16MB1777.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB17779910150BE5A0F7715242EA020BN6PR16MB1777namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3dfb733f-5d42-480d-2a33-08d549261fce X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2017 10:24:03.1111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1779 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6185> : inlines <6277> : streams <1773837> : uri <2555433> Archived-At: Subject: Re: [Dots] DOTS gateway loop handling X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 10:24:14 -0000 --_000_BN6PR16MB17779910150BE5A0F7715242EA020BN6PR16MB1777namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_BN6PR16MB17779910150BE5A0F7715242EA020BN6PR16MB1777namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good poin= t, both drafts can use a mechanism similar to the one discussed in https://tools.iet= f.org/html/rfc7332#section-5 (Max-forwards header).

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 2:53 PM
To: dots@ietf.org
Subject: [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there never should be a l= oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio= n a request can end up getting bounced between a set of (not necessarily ad= jacent) DOTS gateways.

 

We need to make sure that this = loop is broken – possibly by using a mechanism similar to TTL in IP p= ackets.

 

If we agree that loops need to = get broken, this “feature” needs to get added into both the sig= nal and data channels.

 

Regards

 

Jon

--_000_BN6PR16MB17779910150BE5A0F7715242EA020BN6PR16MB1777namp_-- From nobody Fri Dec 22 02:30:23 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691F91243F6 for ; Fri, 22 Dec 2017 02:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRPszFdS8r7V for ; Fri, 22 Dec 2017 02:30:19 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4548126B72 for ; Fri, 22 Dec 2017 02:30:19 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eSKao-0007aX-4J; Fri, 22 Dec 2017 10:30:18 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> In-Reply-To: Date: Fri, 22 Dec 2017 10:30:20 -0000 Message-ID: <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06CF_01D37B0F.DE1D3BA0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQH2IO4WJuCy0mWHgjECz8GquwZNogGntdEDovyfV4A= Archived-At: Subject: Re: [Dots] DOTS gateway loop handling X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 10:30:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06CF_01D37B0F.DE1D3BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainly as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not working as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways, if there is a mis-configuration a request can end up getting bounced between a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechanism similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get added into both the signal and data channels. Regards Jon ------=_NextPart_000_06CF_01D37B0F.DE1D3BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I’m not sure that = we can necessarily support this as a Header, but certainly as a = parameter in the CBOR / JSON

 

I think the most likely = scenario for this loop to happen is if DNS is not working as = expected.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 22 December 2017 = 10:24
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS gateway loop handling

 

Good point, both = drafts can use a mechanism similar to the one discussed in https://tools.ietf= .org/html/rfc7332#section-5 (Max-forwards = header).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 2:53 PM
To: dots@ietf.org
Subject: = [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there = never should be a loop in DOTS traffic going via DOTS gateways, if there = is a mis-configuration a request can end up getting bounced between a = set of (not necessarily adjacent) DOTS gateways.

 

We need to = make sure that this loop is broken – possibly by using a mechanism = similar to TTL in IP packets.

 

If we agree = that loops need to get broken, this “feature” needs to get = added into both the signal and data channels.

 

Regards

 

Jon

------=_NextPart_000_06CF_01D37B0F.DE1D3BA0-- From nobody Fri Dec 22 02:32:36 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF7B126DFF for ; Fri, 22 Dec 2017 02:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VbbGFfMjiJ2 for ; Fri, 22 Dec 2017 02:32:33 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9DA126DEE for ; Fri, 22 Dec 2017 02:32:33 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1513938744; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=W rQ4oJgcpM29IkgPS47g9wI/eDE6C2RPA1o5Js9JC7 M=; b=lO8NstdZpm1YFrcUIPHQDYJmi2wT6A7yMDSc9VAhEIGh wfy8bImTCQxqkFt9PRurEOArLN1D2dWptPxRbmqSdKRAyHjZrQ jUiME6M9iHLz2sL6UlG1IUYl2bjCMG9LaimoOvkqvY6xrQDein XxTsS+yX71ujgv2QIytvNVsXpf8= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 7599_260d_057c959e_6286_42e6_854c_037c49657f63; Fri, 22 Dec 2017 04:32:24 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Dec 2017 05:32:23 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 22 Dec 2017 05:32:23 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Dec 2017 05:32:21 -0500 Received: from BN6PR16MB1777.namprd16.prod.outlook.com (10.172.28.141) by BN6PR16MB1779.namprd16.prod.outlook.com (10.172.28.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Fri, 22 Dec 2017 10:32:20 +0000 Received: from BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) by BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) with mapi id 15.20.0345.013; Fri, 22 Dec 2017 10:32:20 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7wAABvMAAAAAi8kA== Date: Fri, 22 Dec 2017 10:32:20 +0000 Message-ID: References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> In-Reply-To: <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1779; 6:fHnmLvfjVouq5Eg3mOVhMdohMd7d2c4vtEWn1xihEfQCY6zrVVrZGyAz3jvdf8g66ekzhJVXOuKN5q1NXe+0XpIheKm/+DvpCLPcWXbfha42D1yktco0gFctc9JUFWWblkhYjPYRhbul56OmXBIQ12HD1Isju1XXnCc4aZa2hsWss0XGh2RsgjSE3fBXp4tCB0gWBUVrVLag24Pnne9EGhIJmOL+UDPYZFgNU+fp8g9bKatXb322RsDBjBZolCaRJjrkzp59doKPIDJ1dV8P3Gw+7urv0Mth78NX+Ji6EFD7CUmcrJApGte78s+Wcz49S5dO+I+zAc3R0Nh0+9KmGYWzFQsud7wWT05Sm7fts/U=; 5:7Lr6TxKRF2I9UslUrn/DuYOUAA27+ANHDewYdHK4RckpuUNYeRDlgyoEf48Ibt/nNYHa73dDP4b4VNHW6g56s6LAa0hld08dEvGO3B65QPW9x11FviDC3d18x/0JBEE4VSl8ZzLMUn9eqO4uWDNQuMnTY/SFXRaOHTCl3K2Hqwg=; 24:Xpm8ZqvlftWpL0TiZKpnCdm0iNEaQB8ITfJFsExhqxzV/qJ08+EUUWK5zqP5i7XYzUSx9pfDGjsfQeh1C3ITEbJBVhA3I6X1J51mbuSRk84=; 7:m0h2AnuTMmuOchw9dOv1U+/VdfMLQGGkMOsni1YTCQ1GQ4Onyjo2K5jK5Nnc2SFZ4aKyZNd5jgMmo6oScyK5K/S/hiHpQ9v2yBUsGd/mwtaaZ7MkIejcqQnihVm4abOmEEwaRYH3cAinSoJ6ka1e+WI2YvkVUTnOjsGO6hIOLz6WWl46GUv4vTrr56L3W+q5cGubSXZvVHDC0Ueqle5SJSCgFIdT1PMsCW3ydIoBZs396p3v4R881W5gzowvJJcP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c091c4fa-0768-4c74-9269-08d54927483d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008031)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:BN6PR16MB1779; x-ms-traffictypediagnostic: BN6PR16MB1779: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(3231023)(93006095)(93001095)(3002001)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB1779; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR16MB1779; x-forefront-prvs: 05299D545B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(189003)(199004)(32952001)(106356001)(72206003)(316002)(80792005)(97736004)(105586002)(6436002)(66066001)(229853002)(33656002)(77096006)(25786009)(7736002)(5660300001)(110136005)(9686003)(236005)(54896002)(6306002)(6506007)(14454004)(53546011)(2900100001)(81156014)(81166006)(86362001)(3280700002)(6246003)(2950100002)(59450400001)(478600001)(74316002)(76176011)(2501003)(606006)(99286004)(8936002)(966005)(53936002)(2906002)(102836004)(3660700001)(68736007)(6116002)(3846002)(8676002)(19609705001)(790700001)(55016002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1779; H:BN6PR16MB1777.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB17777D9916B70E12ABAEF6EAEA020BN6PR16MB1777namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c091c4fa-0768-4c74-9269-08d54927483d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2017 10:32:20.4437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1779 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6185> : inlines <6277> : streams <1773838> : uri <2555437> Archived-At: Subject: Re: [Dots] DOTS gateway loop handling X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 10:32:35 -0000 --_000_BN6PR16MB17777D9916B70E12ABAEF6EAEA020BN6PR16MB1777namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_BN6PR16MB17777D9916B70E12ABAEF6EAEA020BN6PR16MB1777namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I me= ant as CBOR and JSON parameters.

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, December 22, 2017 4:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru= ,

&n= bsp;

I’= ;m not sure that we can necessarily support this as a Header, but certainly= as a parameter in the CBOR / JSON

&n= bsp;

I think= the most likely scenario for this loop to happen is if DNS is not working = as expected.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 10:24
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] DOTS gateway loop handling

 

Good poin= t, both drafts can use a mechanism similar to the one discussed in https://tools.iet= f.org/html/rfc7332#section-5 (Max-forwards header).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 2:53 PM
To: dots@ietf.org
Subject: [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there never should be a l= oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio= n a request can end up getting bounced between a set of (not necessarily ad= jacent) DOTS gateways.

 

We need to make sure that this = loop is broken – possibly by using a mechanism similar to TTL in IP p= ackets.

 

If we agree that loops need to = get broken, this “feature” needs to get added into both the sig= nal and data channels.

 

Regards

 

Jon

--_000_BN6PR16MB17777D9916B70E12ABAEF6EAEA020BN6PR16MB1777namp_-- From nobody Fri Dec 22 09:11:30 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18400126DFF for ; Fri, 22 Dec 2017 09:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsTimT9gmu3Y for ; Fri, 22 Dec 2017 09:11:28 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14C81271FD for ; Fri, 22 Dec 2017 09:11:27 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eSQqz-0007nG-0X for ietf-supjps-dots@ietf.org; Fri, 22 Dec 2017 17:11:25 +0000 From: "Jon Shallow" To: Date: Fri, 22 Dec 2017 17:11:27 -0000 Message-ID: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0731_01D37B47.E6F581A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdN7R9961HXkMq2tTZepG2+xKMly9Q== Archived-At: Subject: [Dots] Signal CBOR / JSON Mapping X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 17:11:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0731_01D37B47.E6F581A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, There are a lot of YANG parameters that we are using that are defined as int64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. ==== An option is to make all of these int64 decimal64 for the signal channel, but that does not cover the 64 bit counters in the netmod-acl. However, as the netmod-acl counters are also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 64 bits, and as the parameter is a CBOR mapping, we can know how to encode / decode the JSON value as appropriate. However, RFC 7493 does not say whether this should be base64, base64url or numeric string representation (i.e. "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read and easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key to key off how to encode / decode the JSON, I would suggest that we could extend this to include IP addresses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to further minimize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but it is too wide I think) /----------------------+-------------+------+---------------+--------+------ ---\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON | | | | key | type | type | Example | |----------------------+-------------+------+---------------+--------+------ ---| | mitigation-scope | grouping | 1 | 5 map | Object | | | scope | list | 2 | 4 array | Array | | | mitigation-id | int32 | 3 | 0 unsigned | Number | 54321 | | acl-list | list | 4 | 4 array | Array | | | target-port-range | list | 5 | 4 array | Array | | | lower-port | port-number | 6 | 0 number | Number | 1111 | | upper-port | port-number | 7 | 0 number | Number | 1111 | | target-protocol | leaf-list | | 4 array | Array | | | | uint8 | 8 | 0 number | Number | 6 | | target-fqdn | leaf-list | | 4 array | Array | | | | domain-name | 9 | 3 text string | String | "a.com" | | target-uri | leaf-list | | 4 array | Array | | | | uri | 10 | 3 text string | String | | | alias-name | leaf-list | | 4 array | Array | | | | string | 11 | 3 text string | String | "web" | | lifetime | int32 | 12 | 0 number | Number | | | attack-status | enumeration | 13 | 0 number | Number | 1 | | signal-config | grouping | 14 | 5 map | Object | | | heartbeat-interval | grouping | 15 | 5 map | Object | | | max-retransmit | grouping | 16 | 5 map | Object | | | ack-timeout | grouping | 17 | 5 map | Object | | | ack-random-factor | grouping | 18 | 5 map | Object | | | min-value | int16 | 19 | 0 number | Number | 1 | | max-value | int16 | 20 | 0 number | Number | 1 | | status | enumeration | 21 | 0 number | Number | 1 | | conflict-information | grouping | 22 | 5 map | Object | | | conflict-status | enumeration | 23 | 0 number | Number | 1 | | conflict-cause | enumeration | 24 | 0 number | Number | 1 | | retry-timer | int32 | 25 | 0 number | Number | 1800 | | bytes-dropped | counter64 | 26 | 0 number | String | "1234" | | bps-dropped | counter64 | 27 | 0 number | String | "1234" | | pkts-dropped | counter64 | 28 | 0 number | String | "1234" | | pps-dropped | counter64 | 29 | 0 number | String | "1234" | | session-id | int32 | 30 | 0 number | Number | 65432 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | | | missing-hb-allowed | grouping | 32 | 5 map | Object | | | current-value | int16 | 33 | 0 number | Number | 10 | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.21 | | target-prefix | leaf-list | | 4 array | Array | | | | ip-prefix | 35 | 3 text string | String | | | client-domain-hash | leaf-list | | 4 array | Array | | | | binary | 36 | 2 byte string | String | "abcdf" | | alt-server | string | 37 | 3 text string | String | | | alt-server-record | list | 38 | 4 array | Array | | | addr | string | 39 | 3 text string | String | | | ttl | int32 | 40 | 0 number | Number | 1800 | | conflict-scope | grouping | 41 | 5 map | Object | | | acl-name | string | 42 | 3 text string | String | "aname" | | acl-type | string | 43 | 3 text string | String | "ipv4" | | config-interval | int32 | 44 | 0 number | Number | 11 | | mitigating-config | grouping | 45 | 5 map | Object | | | idle-config | grouping | 46 | 5 map | Object | | | request-nonce | binary | 47 | 2 byte string | String | "xxx" | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 | \----------------------+-------------+------+---------------+--------+------ ---/ Comments / suggestions? Regards Jon ------=_NextPart_000_0731_01D37B47.E6F581A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

There are a lot of YANG parameters that we are using = that are defined as int64.  JSON only safely supports up to 53 bits = of precision.

 

RFC 7493 2.2 Numbers

 

   = An I-JSON sender cannot expect a receiver to treat an integer = whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range [-(2**53)+1, = (2**53)-1]) as an exact value.

 

   = For applications that require the exact interchange of numbers = with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values.  This requires = that the receiving program

   understand the intended semantic of the = value.  An example would be

   64-bit integers, even though modern = hardware can deal with them,

   because of the limited scope of = JavaScript numbers.

 

RFC7049 3.6 = Numbers

 

   CBOR-based protocols should take into = account that different language

   environments pose different restrictions = on the range and precision

   of numbers that are representable.  = For example, the JavaScript

   number system treats all numbers as = floating point, which may result

   in silent loss of precision in decoding = integers with more than 53

   significant bits.  A protocol that = uses numbers should define its

   expectations on the handling of = non-trivial numbers in decoders and

   receiving applications.

 

=3D=3D=3D=3D

 

An option is = to make all of these int64 decimal64 for the signal channel, but that = does not cover the 64 bit counters in the netmod-acl.  However, as = the netmod-acl counters are also fed back via the mitigate status, we do = not necessarily need to support the netmod-acl = counters.

 

If, however, we follow RFC 7493, in CBOR the data can = be passed across as 64 bits, and as the parameter is a CBOR mapping, we = can know how to encode / decode the JSON value as appropriate.  = However, RFC 7493 does not say whether this should be base64, base64url = or numeric string representation (i.e. “1234567890”). =  RFC7049 refers to bignum (major type 6, tag value 2 or 3) should = be encoded as base64url (4.1 Converting from CBOR to JSON) – but = int64 can be held in CBOR as type 0 or 1.

 

I prefer the = numeric string representation as it is humanly easy to read and easy to = convert into 64 bit integers.

 

If we take = this approach of using the parameter which is a CBOR mapping key to key = off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or = their possible new names of request-nonce and client-domain-hash) to = further minimize the actual number of bytes sent in a COAP = packet.

 

The CBOR mapping Table could then be extended to look = something like (but it is too wide I think)

 

/----------------------+-------------+------+--------------= -+--------+---------\

| Parameter = name       | YANG type   | CBOR = | CBOR major    | JSON   | = JSON    | 

|         &nbs= p;            = |            = | key  | = type          | = type   | Example |

|----------------------+-------------+------+--------------= -+--------+---------|

| = mitigation-scope     | grouping    = |   1  | 5 = map         | Object = |         |  =

| = scope           &n= bsp;    | list        = |   2  | 4 array       | = Array  |         |  =

| = mitigation-id        | = int32       |   3  | 0 = unsigned    | Number | 54321   |  =

| = acl-list        =      | = list        |   4  | 4 = array       | Array  = |         |  =

| = target-port-range    | = list        |   5  | 4 = array       | Array  = |         |  =

| = lower-port           | = port-number |   6  | 0 = number      | Number | 1111    = | 

| = upper-port           | = port-number |   7  | 0 = number      | Number | 1111    = | 

| = target-protocol      | leaf-list   = |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uint8       |   8  | 0 = number      | Number | = 6       |

| = target-fqdn          | = leaf-list   |      | 4 = array       | Array  = |         = |

|         &nbs= p;            | = domain-name |   9  | 3 text string | String | = "a.com" |

| = target-uri           | = leaf-list   |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uri         |  10  | 3 = text string | String |         = |

| = alias-name           | = leaf-list   |      | 4 = array       | Array  | =         |  =

| =             &= nbsp;        | = string      |  11  | 3 text string | = String | "web"   | 

| = lifetime           = ;  | int32       |  12  | 0 = number      | Number = |         |  =

| = attack-status        | enumeration = |  13  | 0 number      | Number | = 1       | 

| signal-config        = | grouping    |  14  | 5 = map         | Object = |         |  =

| = heartbeat-interval   | grouping    |  = 15  | 5 map         | = Object |         |  =

| = max-retransmit       | = grouping    |  16  | 5 = map         | Object = |         |  =

| = ack-timeout          | = grouping    |  17  | 5 = map         | Object = |         |  =

| = ack-random-factor    | grouping    |  = 18  | 5 map         | = Object |         |  =

| = min-value   =          | = int16       |  19  | 0 = number      | Number | = 1       | 

| = max-value          &nbs= p; | int16       |  20  | 0 = number      | Number | = 1       | 

| = status           &= nbsp;   | enumeration |  21  | 0 = number      | Number | = 1       | 

| conflict-information | grouping    = |  22  | 5 map         = | Object |         |  =

| = conflict-status      | enumeration |  = 23  | 0 number      | Number | = 1       | 

| conflict-cause       | = enumeration |  24  | 0 number      | = Number | 1       |  =

| = retry-timer          | = int32       |  25  | 0 = number      | Number | 1800    = | 

| = bytes-dropped        | = counter64   |  26  | 0 = number      | String | "1234"  = | 

| = bps-dropped          | = counter64   |  27  | 0 = number      | String | "1234"  = | 

| = pkts-dropped         | counter64 =   |  28  | 0 number      | = String | "1234"  | 

| = pps-dropped          | = counter64   |  29  | 0 = number      | String | "1234"  = | 

| = session-id           | = int32       |  30  | 0 = number      | Number | 65432   = | 

| = trigger-mitigation   | boolean     |  = 31  | 7 simple      | T / F  = |         |  =

| = missing-hb-allowed   | grouping    |  = 32  | 5 map         | = Object |         |  =

| = current-value        | = int16       |  33  | 0 = number      | Number | = 10      | 

| mitigation-start     | = decimal64   |  34  | 7 = FP          | Number | = 10.21   | 

| target-prefix        = | leaf-list   |      | 4 = array       | Array  = |         |  =

| =             &= nbsp;        | = ip-prefix   |  35  | 3 text string | String = |         |  =

| = client-domain-hash   | leaf-list   |  =     | 4 array       | = Array  |         = |

| =             &= nbsp;        | = binary      |  36  | 2 byte string | = String | "abcdf" |

| = alt-server           | = string      |  37  | 3 text string | = String |         |  =

| = alt-server-record    | = list        |  38  | 4 = array       | Array  = |         |  =

| = addr           &nb= sp;     | string      = |  39  | 3 text string | String = |         |  =

| = ttl           &nbs= p;      | = int32       |  40  | 0 = number      | Number | 1800    = | 

| = conflict-scope       | = grouping    |  41  | 5 = map         | Object = |         |  =

| = acl-name           = ;  | string      |  42  | 3 text = string | String | "aname" | 

| = acl-type           = ;  | string      |  43  | 3 text = string | String | "ipv4"  |  =

| = config-interval      | = int32       |  44  | 0 = number      | Number | = 11      | 

| mitigating-config    | = grouping    |  45  | 5 = map         | Object = |         |  =

| = idle-config          | = grouping    |  46  | 5 = map         | Object = |         |  =

| = request-nonce        | = binary      |  47  | 2 byte string | = String | "xxx"   | 

| min-value-decimal    | = decimal64   |  48  | 7 = FP          | Number | = 1.1     | 

| max-value-decimal    | = decimal64   |  49  | 7 = FP          | Number | = 1.1     | 

| current-value-decimal| decimal64   |  = 50  | 7 FP          | = Number | 1.1     | 

\----------------------+-------------+------+--------------= -+--------+---------/

 

 

Comments / = suggestions?

 

Regards

 

Jon

------=_NextPart_000_0731_01D37B47.E6F581A0-- From nobody Fri Dec 22 23:06:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12FA1242EA for ; Fri, 22 Dec 2017 23:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDrCfIEBB-x8 for ; Fri, 22 Dec 2017 23:06:22 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06E51200F1 for ; Fri, 22 Dec 2017 23:06:21 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1514012780; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=N833U+nUy5YRJiZ5+U68AoHDCxfJGcH5W29OFR dKqKo=; b=S0jXCfAGmSX2UwaPVlJEiXUQtCGEZ/YITiF9mcIE YToRHx/Emb1GL2D8sEbfa6iFwnz/mkNakMSIRchfH1JdKKK3Tx 8QiVKk6PIBkc7D2LLlNc8HnJjnW/egQjYUq1aJV7R2i8RBwPbe VbV+pruuimRZw4uQLstZX5HwGC8yx/w= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c50_2bac_d6e4e8b1_bc54_4f19_8b7e_01083db2f410; Sat, 23 Dec 2017 01:06:19 -0600 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 23 Dec 2017 02:06:18 -0500 Received: from MIVEX10N02.corpzone.internalzone.com (10.48.48.170) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 23 Dec 2017 02:06:18 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEX10N02.corpzone.internalzone.com (10.48.48.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 23 Dec 2017 02:06:18 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 23 Dec 2017 02:06:17 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Sat, 23 Dec 2017 07:06:16 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0345.013; Sat, 23 Dec 2017 07:06:16 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal CBOR / JSON Mapping Thread-Index: AdN7R9961HXkMq2tTZepG2+xKMly9QAclUqw Date: Sat, 23 Dec 2017 07:06:16 +0000 Message-ID: References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> In-Reply-To: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:HNR+/WMRBC/ui/DHi6OukAzoniDryedpU3vmCmyDGkOPDE9l23ctdLQ4tNHuq3A1rjJKOemhnaZh6H0iFjMLMp+BKaW1Ffe2PVOEtzG3HWCICDmOLmmVHiPp4NBO31xanLDIU1p8OjAz+ofacqan2RZS8zAcGy/+CdXZosCuJreHtCSrfF6rWg7UduLyG6kx/We5zfgpcp+aCFc2rOjsYJPeF/yh3qwAGxiKRIO5d3Jmj189BL1zCwiTPcGb83lk9sq+yYLSUsbWW+UwlbDBCsOpf2RnMm5Ae6YMg3zpnzJEvabb3tNIro5jNiFKDA99Y/ZjFRx0E/sF+fVlaIhuMlVx3o2mBs59iP3BPHbTqXE=; 5:9EIEEtOwmo9vLLss4BfI3tR+SYu62I60z9yIWz7KK4PdcjqT/TNHnxjDmf8LTUDup76bKg0tVpVWXK45UAJcxShiGls6BWN2DiV0oBaak+NNRPm2qD0FWbMkbz9Q+Ak1zJgWrUNGvpaPFw84WV5TJkP6AxwjI4+UoTWNsvhMZKs=; 24:wV/cnBxmD25o4MGFx2ZF+0P33IdeCAV1Fe0jETsbLoj8iS2ZkhP6rvt1VVV0vdMmCJNmYoh5D2QkzDCJPgh7Upk1x+Djepbnt4dytVODADM=; 7:AWj1QpnFXWzRNYGHogkcCFCve1JUDLnOJNM3V+oMi6BW5clFOdoOLUAo1i/kl/+C3dAt8NzCy9R38sqFAAnTKeNkQeuUvQ30zDDLR0k4Xt+Z3oU1yvAmThBR5EV44oSQ9IiuQu0yS5iKlqsMApi06QOk9w/HB3ARBr88QhLgSgoutCgGpzfl+BOohXa7NMgJLz2KMbc83JN8/yLOsVQ3eeRx1gWQ0awrLkcT5Oi3ojoUSXiJh2vq1tNM2Pk3RVcx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6986c04f-18b0-403b-6664-08d549d3a8fa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3231023)(93006095)(93001095)(3002001)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0530FCB552 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(376002)(366004)(39860400002)(346002)(32952001)(199004)(189003)(102836004)(74316002)(6506007)(105586002)(53546011)(66066001)(14454004)(7736002)(72206003)(478600001)(106356001)(8936002)(68736007)(7696005)(59450400001)(81166006)(97736004)(8676002)(80792005)(76176011)(99286004)(2900100001)(81156014)(86362001)(2906002)(55016002)(77096006)(2501003)(790700001)(25786009)(6116002)(3846002)(5660300001)(2950100002)(110136005)(33656002)(9686003)(3660700001)(6246003)(54896002)(966005)(19609705001)(6306002)(53936002)(3280700002)(316002)(229853002)(6436002)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JYURHJIZiyFLI/Ym0kXEHNw2tB1jxRsqT/MFCndoef2ZIdFt9rqrvgZMsz9d4VGTuPFdudnrB+691GAb2J2X3A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788EFD54B8F039E64C9913EEA030DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6986c04f-18b0-403b-6664-08d549d3a8fa X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2017 07:06:16.2202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6186> : inlines <6281> : streams <1773919> : uri <2555927> Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 07:06:25 -0000 --_000_DM5PR16MB1788EFD54B8F039E64C9913EEA030DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should just follow the CBOR Encoding of Data Modeled with YANG defined i= n https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encodin= g of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as in= t64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. =3D=3D=3D=3D An option is to make all of these int64 decimal64 for the signal channel, b= ut that does not cover the 64 bit counters in the netmod-acl. However, as = the netmod-acl counters are also fed back via the mitigate status, we do no= t necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 6= 4 bits, and as the parameter is a CBOR mapping, we can know how to encode /= decode the JSON value as appropriate. However, RFC 7493 does not say whet= her this should be base64, base64url or numeric string representation (i.e.= "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) = should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int= 64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read an= d easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key= to key off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or their= possible new names of request-nonce and client-domain-hash) to further min= imize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but i= t is too wide I think) /----------------------+-------------+------+---------------+--------+-----= ----\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON= | | | | key | type | type | Exam= ple | |----------------------+-------------+------+---------------+--------+-----= ----| | mitigation-scope | grouping | 1 | 5 map | Object | = | | scope | list | 2 | 4 array | Array | = | | mitigation-id | int32 | 3 | 0 unsigned | Number | 5432= 1 | | acl-list | list | 4 | 4 array | Array | = | | target-port-range | list | 5 | 4 array | Array | = | | lower-port | port-number | 6 | 0 number | Number | 1111= | | upper-port | port-number | 7 | 0 number | Number | 1111= | | target-protocol | leaf-list | | 4 array | Array | = | | | uint8 | 8 | 0 number | Number | 6 = | | target-fqdn | leaf-list | | 4 array | Array | = | | | domain-name | 9 | 3 text string | String | "a.c= om" | | target-uri | leaf-list | | 4 array | Array | = | | | uri | 10 | 3 text string | String | = | | alias-name | leaf-list | | 4 array | Array | = | | | string | 11 | 3 text string | String | "web= " | | lifetime | int32 | 12 | 0 number | Number | = | | attack-status | enumeration | 13 | 0 number | Number | 1 = | | signal-config | grouping | 14 | 5 map | Object | = | | heartbeat-interval | grouping | 15 | 5 map | Object | = | | max-retransmit | grouping | 16 | 5 map | Object | = | | ack-timeout | grouping | 17 | 5 map | Object | = | | ack-random-factor | grouping | 18 | 5 map | Object | = | | min-value | int16 | 19 | 0 number | Number | 1 = | | max-value | int16 | 20 | 0 number | Number | 1 = | | status | enumeration | 21 | 0 number | Number | 1 = | | conflict-information | grouping | 22 | 5 map | Object | = | | conflict-status | enumeration | 23 | 0 number | Number | 1 = | | conflict-cause | enumeration | 24 | 0 number | Number | 1 = | | retry-timer | int32 | 25 | 0 number | Number | 1800= | | bytes-dropped | counter64 | 26 | 0 number | String | "123= 4" | | bps-dropped | counter64 | 27 | 0 number | String | "123= 4" | | pkts-dropped | counter64 | 28 | 0 number | String | "123= 4" | | pps-dropped | counter64 | 29 | 0 number | String | "123= 4" | | session-id | int32 | 30 | 0 number | Number | 6543= 2 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | = | | missing-hb-allowed | grouping | 32 | 5 map | Object | = | | current-value | int16 | 33 | 0 number | Number | 10 = | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.2= 1 | | target-prefix | leaf-list | | 4 array | Array | = | | | ip-prefix | 35 | 3 text string | String | = | | client-domain-hash | leaf-list | | 4 array | Array | = | | | binary | 36 | 2 byte string | String | "abc= df" | | alt-server | string | 37 | 3 text string | String | = | | alt-server-record | list | 38 | 4 array | Array | = | | addr | string | 39 | 3 text string | String | = | | ttl | int32 | 40 | 0 number | Number | 1800= | | conflict-scope | grouping | 41 | 5 map | Object | = | | acl-name | string | 42 | 3 text string | String | "ana= me" | | acl-type | string | 43 | 3 text string | String | "ipv= 4" | | config-interval | int32 | 44 | 0 number | Number | 11 = | | mitigating-config | grouping | 45 | 5 map | Object | = | | idle-config | grouping | 46 | 5 map | Object | = | | request-nonce | binary | 47 | 2 byte string | String | "xxx= " | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 = | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 = | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 = | \----------------------+-------------+------+---------------+--------+-----= ----/ Comments / suggestions? Regards Jon --_000_DM5PR16MB1788EFD54B8F039E64C9913EEA030DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should just follow the CBOR Encoding of Data Modeled = with YANG defined in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-= 05 and JSON Encoding of Data Modeled with YANG

defined in https://tools.ietf.org/html/= rfc7951.

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 10:41 PM
To: dots@ietf.org
Subject: [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a lot of YANG paramet= ers that we are using that are defined as int64.  JSON only safely sup= ports up to 53 bits of precision.

 

RFC 7493 2.2 Numbers=

 

   An I-JSON sender c= annot expect a receiver to treat an integer whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range = [-(2**53)+1, (2**53)-1]) as an exact value.

 

   For applications t= hat require the exact interchange of numbers with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values= .  This requires that the receiving program

   understand the int= ended semantic of the value.  An example would be

   64-bit integers, e= ven though modern hardware can deal with them,

   because of the lim= ited scope of JavaScript numbers.

 

RFC7049 3.6 Numbers<= /span>

 

   CBOR-based protoco= ls should take into account that different language

   environments pose = different restrictions on the range and precision

   of numbers that ar= e representable.  For example, the JavaScript

   number system trea= ts all numbers as floating point, which may result

   in silent loss of = precision in decoding integers with more than 53

   significant bits.&= nbsp; A protocol that uses numbers should define its

   expectations on th= e handling of non-trivial numbers in decoders and

   receiving applicat= ions.

 

=3D=3D=3D=3D<= /p>

 

An option is to make all of the= se int64 decimal64 for the signal channel, but that does not cover the 64 b= it counters in the netmod-acl.  However, as the netmod-acl counters ar= e also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters.<= /span>

 

If, however, we follow RFC 7493= , in CBOR the data can be passed across as 64 bits, and as the parameter is= a CBOR mapping, we can know how to encode / decode the JSON value as appro= priate.  However, RFC 7493 does not say whether this should be base64, base64url or numeric string representat= ion (i.e. “1234567890”).  RFC7049 refers to bignum (major = type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting fr= om CBOR to JSON) – but int64 can be held in CBOR as type 0 or 1.

 

I prefer the numeric string rep= resentation as it is humanly easy to read and easy to convert into 64 bit i= ntegers.

 

If we take this approach of usi= ng the parameter which is a CBOR mapping key to key off how to encode / dec= ode the JSON, I would suggest that we could extend this to include IP addre= sses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to furth= er minimize the actual number of bytes sent in a COAP packet.

 

The CBOR mapping Table could th= en be extended to look something like (but it is too wide I think)

 

/----------------------+-------------= 3;------+---------------+--------+---------\<= /p>

| Parameter name    &nbs= p;  | YANG type   | CBOR | CBOR major    | JS= ON   | JSON    | 

|       &= nbsp;           &nbs= p;  |           = ;  | key  | type        &= nbsp; | type   | Example |

|----------------------+-------------= 3;------+---------------+--------+---------|<= /p>

| mitigation-scope     |= grouping    |   1  | 5 map   =       | Object |     &nbs= p;   | 

| scope      &= nbsp;         | list  &nb= sp;     |   2  | 4 array  &nbs= p;    | Array  |      &nb= sp;  | 

| mitigation-id     = ;   | int32       |   3&n= bsp; | 0 unsigned    | Number | 54321   | 

| acl-list     &nbs= p;       | list     =    |   4  | 4 array     &= nbsp; | Array  |         |&nbs= p;

| target-port-range    | list=         |   5  | 4 array&= nbsp;      | Array  |    =      | 

| lower-port     &n= bsp;     | port-number |   6  | 0 number=       | Number | 1111    | 

| upper-port     &n= bsp;     | port-number |   7  | 0 number=       | Number | 1111    | 

| target-protocol    &nb= sp; | leaf-list   |      | 4 array =       | Array  |     = ;    | 

|       &= nbsp;           &nbs= p;  | uint8       |   8  = | 0 number      | Number | 6   &nbs= p;   |

| target-fqdn     &= nbsp;    | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       |

|       &= nbsp;           &nbs= p;  | domain-name |   9  | 3 text string | String | &qu= ot;a.com" |

| target-uri     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  |&nbs= p;        | 

|       &= nbsp;           &nbs= p;  | uri         |  10&n= bsp; | 3 text string | String |       &n= bsp; |

| alias-name     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       | 

|        =             &nb= sp; | string      |  11  | 3 text s= tring | String | "web"   | 

| lifetime     &nbs= p;       | int32     = ;  |  12  | 0 number      | Number = |         | 

| attack-status     = ;   | enumeration |  13  | 0 number   &n= bsp;  | Number | 1       | 

| signal-config     = ;   | grouping    |  14  | 5 map &n= bsp;       | Object |    =      | 

| heartbeat-interval   | grouping&= nbsp;   |  15  | 5 map     &nb= sp;   | Object |         = | 

| max-retransmit    &nbs= p;  | grouping    |  16  | 5 map  &= nbsp;      | Object |     = ;    | 

| ack-timeout     &= nbsp;    | grouping    |  17  | 5 m= ap         | Object |  &n= bsp;      | 

| ack-random-factor    | grou= ping    |  18  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| min-value      &n= bsp;     | int16     &nbs= p; |  19  | 0 number      | Number | 1&n= bsp;      | 

| max-value     &nb= sp;      | int16     &nbs= p; |  20  | 0 number      | Number | 1&n= bsp;      | 

| status      =          | enumeration |  21&n= bsp; | 0 number      | Number | 1   = ;    | 

| conflict-information | grouping  = ;  |  22  | 5 map       &= nbsp; | Object |         | 

| conflict-status    &nb= sp; | enumeration |  23  | 0 number     = | Number | 1       | 

| conflict-cause    &nbs= p;  | enumeration |  24  | 0 number    &= nbsp; | Number | 1       | 

| retry-timer     &= nbsp;    | int32       | = 25  | 0 number      | Number | 1800 &nb= sp;  | 

| bytes-dropped     = ;   | counter64   |  26  | 0 number &nbs= p;    | String | "1234"  | 

| bps-dropped     &= nbsp;    | counter64   |  27  | 0 number=       | String | "1234"  | 

| pkts-dropped     =     | counter64   |  28  | 0 number = ;     | String | "1234"  | 

| pps-dropped     &= nbsp;    | counter64   |  29  | 0 number=       | String | "1234"  | 

| session-id     &n= bsp;     | int32       |&= nbsp; 30  | 0 number      | Number | 65432&nb= sp;  | 

| trigger-mitigation   | boolean&n= bsp;    |  31  | 7 simple    &= nbsp; | T / F  |         |&nbs= p;

| missing-hb-allowed   | grouping&= nbsp;   |  32  | 5 map     &nb= sp;   | Object |         = | 

| current-value     = ;   | int16       |  33  = | 0 number      | Number | 10   &nb= sp;  | 

| mitigation-start     |= decimal64   |  34  | 7 FP     = ;     | Number | 10.21   | 

| target-prefix     = ;   | leaf-list   |      | 4 a= rray       | Array  |   &= nbsp;     | 

|        =             &nb= sp; | ip-prefix   |  35  | 3 text string | String = |         | 

| client-domain-hash   | leaf-list=    |      | 4 array   &nb= sp;   | Array  |       &n= bsp; |

|        =             &nb= sp; | binary      |  36  | 2 byte s= tring | String | "abcdf" |

| alt-server     &n= bsp;     | string      | = 37  | 3 text string | String |      &nb= sp;  | 

| alt-server-record    | list=         |  38  | 4 array =       | Array  |     = ;    | 

| addr      &n= bsp;          | string &n= bsp;    |  39  | 3 text string | String | &nb= sp;       | 

| ttl      &nb= sp;           | int32&nbs= p;      |  40  | 0 number  &nb= sp;   | Number | 1800    | 

| conflict-scope    &nbs= p;  | grouping    |  41  | 5 map  &= nbsp;      | Object |     = ;    | 

| acl-name     &nbs= p;       | string    &nbs= p; |  42  | 3 text string | String | "aname" | 

| acl-type     &nbs= p;       | string    &nbs= p; |  43  | 3 text string | String | "ipv4"  |&nbs= p;

| config-interval    &nb= sp; | int32       |  44  | 0 number=       | Number | 11      = | 

| mitigating-config    | grou= ping    |  45  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| idle-config     &= nbsp;    | grouping    |  46  | 5 m= ap         | Object |  &n= bsp;      | 

| request-nonce     = ;   | binary      |  47  | 2 b= yte string | String | "xxx"   | 

| min-value-decimal    | deci= mal64   |  48  | 7 FP     &nbs= p;    | Number | 1.1     | 

| max-value-decimal    | deci= mal64   |  49  | 7 FP     &nbs= p;    | Number | 1.1     | 

| current-value-decimal| decimal64 &nbs= p; |  50  | 7 FP        &= nbsp; | Number | 1.1     | 

\----------------------+-------------= 3;------+---------------+--------+---------/<= /p>

 

 

Comments / suggestions?

 

Regards

 

Jon

--_000_DM5PR16MB1788EFD54B8F039E64C9913EEA030DM5PR16MB1788namp_-- From nobody Thu Dec 28 02:01:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6755D126B6D for ; Thu, 28 Dec 2017 02:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUBm5R9AQsrK for ; Thu, 28 Dec 2017 02:01:55 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4112D86C for ; Thu, 28 Dec 2017 02:01:54 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 8C68425F691 for ; Thu, 28 Dec 2017 19:01:52 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 643647634F9 for ; Thu, 28 Dec 2017 19:01:52 +0900 (JST) To: dots@ietf.org From: kaname nishizuka Message-ID: Date: Thu, 28 Dec 2017 19:01:53 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 10:01:57 -0000 Hi, Last week, Jon and I did the second interoperability test based on the -13 version of the signal channel draft. We made significant improvements of each implementation. Several feedbacks to the WG have been made by Jon already. Based on the experience, I encountered the problems between CoAP libraries and the specification of the DOTS. 1. resource identification of GET methods. In signal channel spec, the target resource in GET method is identified in the BODY of the message, that is mitigation-id (and client-identifier). However, CoAP libraries, at least we investigated, only see the Request URI, so it cannot locate the resource because it doesn't see the BODY. So the question is, why does the DOTS spec use CoAP Body for resource identifier? Most of CoAP libraries only support request URI in CoAP GET/observe, which is the spec from RFC7252. https://tools.ietf.org/html/rfc7252 5.8.1.GET   The GET method retrieves a representation for the information that   currently corresponds to the resource identified by the request URI. 2. Confirmable vs NonConfirmable at Mitigation Request A CoAP library (dustin/go-coap) stops listening right after sending out the NonConfirmable message because NonConfirmable messages do not require acknowledgements. The spec of Confirmable message already have the retransmission mechanism, so using Confirmable message is an easier way to notice that the message has been lost during the attack time. I'm afraid I'm missing some previous discussions we made on the ML and at the WG meeting, but we have a problem with the CoAP library regarding this spec. * At the -08 version of the signal channel draft, this change was made: DOTS mitigation request/response are marked as non-confirmable messages. thank you, Kaname From nobody Thu Dec 28 13:01:09 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A8B12D851 for ; Thu, 28 Dec 2017 13:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olRvPjAnyt5l for ; Thu, 28 Dec 2017 13:01:04 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C9612D7EB for ; Thu, 28 Dec 2017 13:01:04 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eUfIS-0003ZK-0M; Thu, 28 Dec 2017 21:01:00 +0000 From: "Jon Shallow" To: "'kaname nishizuka'" , References: In-Reply-To: Date: Thu, 28 Dec 2017 21:01:01 -0000 Message-ID: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQLSq4q/0bL2TF/Kn5VRXUOjWNcfvqFaY6yw Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 21:01:08 -0000 Hi Kaname, See inline [Jon]. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 28 December 2017 10:02 To: dots@ietf.org Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with = the DOTS spec Hi, Last week, Jon and I did the second interoperability test based on the = -13 version of the signal channel draft. We made significant improvements of each implementation. Several = feedbacks to the WG have been made by Jon already. Based on the experience, I encountered the problems between CoAP = libraries and the specification of the DOTS. 1. resource identification of GET methods. In signal channel spec, the target resource in GET method is identified = in the BODY of the message, that is mitigation-id (and = client-identifier). However, CoAP libraries, at least we investigated, only see the Request = URI, so it cannot locate the resource because it doesn't see the BODY. So the question is, why does the DOTS spec use CoAP Body for resource = identifier? [Jon] A very good question. I had just assumed that this was the way to = do it, but had noted that this was not done when using HTTP etc. and so = was different. See later comments Most of CoAP libraries only support request URI in CoAP GET/observe, = which is the spec from RFC7252. https://tools.ietf.org/html/rfc7252 5.8.1.GET The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. [Jon] RFC 7252 states also 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to specify the target resource of a request to a CoAP origin server. [Jon] So it looks like the target resource should only be in Uri-Path = and/or Uri-Query.=20 [Jon] In my CoAP Library, I have to define each individual resource (it = does a lookup against a hash of the complete Uri to find whether the = resource is known or not), so, when say mitigation-id=3D2 is added, I = need to register the resource = .well-known/dots/v1/mitigate/migration-is=3D2 with an associated = handler. This is not difficult to do, but potentially could consume a = lot of DOTS server resources if many mitigations are active. [Jon] Doing it as a Query Option I think is my preference - Comments? [Jon] The same is true for GET signal configuration as well. 2. Confirmable vs NonConfirmable at Mitigation Request A CoAP library (dustin/go-coap) stops listening right after sending out = the NonConfirmable message because NonConfirmable messages do not = require acknowledgements. [Jon] As there is a good chance during attack scenarios that responses = may not be able to get back, it makes sense to me that these "GET = mitigation" requests are non-confirmable. Certainly "PUT mitigation" = needs to be thought of as a one way signal. There are times that the = client has to run "blind" during attack scenarios. [Jon]If they were confirmable, then the request will get sent multiple = times to the DOTS server - which could be handled by the server, but = then the confirmable responses would retried whilst sending back to the = DOTS client and eventually retry timeout. A large scale attack could = swamp a DOTS server with all the yet to be confirmed confirmable = responses. [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a = non-confirmable request is expected to be handled as in:- If a request is sent in a Non-confirmable message, then the response is sent using a new Non-confirmable message, although the server may instead send a Confirmable message. This type of exchange is illustrated in Figure 6. Client Server | | | NON [0x7a11] | | GET /temperature | | (Token 0x74) | +----------------->| | | | NON [0x23bc] | | 2.05 Content | | (Token 0x74) | | "22.5 C" | |<-----------------+ | | Figure 6: A Request and a Response Carried in Non-confirmable Messages [Jon] So I would expect any CoAP library to support this = non-confirmation mechanism by receiving a new non-confirmable message. = It would be the responsibility of the DOTS layer to associate the Tokens = together to handle the responses with the requests. [Jon] In addition, when Observe is enabled, the DOTS server will = continue to generate non-confirmable messages with the same Token. = Again, the DOTS client will need to know what to do with the Token = (which could be to update things, or to send a RST if no more packets = with the same Token should be sent. The spec of Confirmable message already have the retransmission = mechanism, so using Confirmable message is an easier way to notice that = the message has been lost during the attack time. [Jon] The DOTS client will know something is wrong as it will be seeing = heartbeat issues. I'm afraid I'm missing some previous discussions we made on the ML and = at the WG meeting, but we have a problem with the CoAP library regarding = this spec. * At the -08 version of the signal channel draft, this change was made: DOTS mitigation request/response are marked as non-confirmable messages. thank you, Kaname _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Dec 28 13:02:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77DA12D7EB for ; Thu, 28 Dec 2017 13:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxnOA8jif9OD for ; Thu, 28 Dec 2017 13:02:11 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3FD12D80F for ; Thu, 28 Dec 2017 13:02:10 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eUfJZ-0003Zh-38; Thu, 28 Dec 2017 21:02:09 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> In-Reply-To: Date: Thu, 28 Dec 2017 21:02:10 -0000 Message-ID: <094a01d3801f$20d94dd0$628be970$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_094B_01D3801F.20DB97C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJTmGwWHKq+N1BT2oAOspP+fqvZXQF5x90coksLBgA= Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 21:02:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_094B_01D3801F.20DB97C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving forward. However, my JSON implementation (as well as many others I suspect) natively supports decimal64, so does not necessarily need to display it as a lexical representation string. Do we follow RFC7951 here as well? I do not think that we should be following the augmented JSON parameter naming in RFC7951 "4. Names and Namespaces" otherwise we will start ending up with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope". If we do go with this, then the CBOR mapping table will need to get extended to cover the old, but some parameter name in different places. Comments? As we are working with YANG, JSON and CBOR interrelation , I still think we need a table similar to below to aid implementers - referring as appropriate to the different RFCs - no-one has full knowledge of all the evolving RFCs. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as int64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. ==== An option is to make all of these int64 decimal64 for the signal channel, but that does not cover the 64 bit counters in the netmod-acl. However, as the netmod-acl counters are also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 64 bits, and as the parameter is a CBOR mapping, we can know how to encode / decode the JSON value as appropriate. However, RFC 7493 does not say whether this should be base64, base64url or numeric string representation (i.e. "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read and easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key to key off how to encode / decode the JSON, I would suggest that we could extend this to include IP addresses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to further minimize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but it is too wide I think) /----------------------+-------------+------+---------------+--------+------ ---\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON | | | | key | type | type | Example | |----------------------+-------------+------+---------------+--------+------ ---| | mitigation-scope | grouping | 1 | 5 map | Object | | | scope | list | 2 | 4 array | Array | | | mitigation-id | int32 | 3 | 0 unsigned | Number | 54321 | | acl-list | list | 4 | 4 array | Array | | | target-port-range | list | 5 | 4 array | Array | | | lower-port | port-number | 6 | 0 number | Number | 1111 | | upper-port | port-number | 7 | 0 number | Number | 1111 | | target-protocol | leaf-list | | 4 array | Array | | | | uint8 | 8 | 0 number | Number | 6 | | target-fqdn | leaf-list | | 4 array | Array | | | | domain-name | 9 | 3 text string | String | "a.com" | | target-uri | leaf-list | | 4 array | Array | | | | uri | 10 | 3 text string | String | | | alias-name | leaf-list | | 4 array | Array | | | | string | 11 | 3 text string | String | "web" | | lifetime | int32 | 12 | 0 number | Number | | | attack-status | enumeration | 13 | 0 number | Number | 1 | | signal-config | grouping | 14 | 5 map | Object | | | heartbeat-interval | grouping | 15 | 5 map | Object | | | max-retransmit | grouping | 16 | 5 map | Object | | | ack-timeout | grouping | 17 | 5 map | Object | | | ack-random-factor | grouping | 18 | 5 map | Object | | | min-value | int16 | 19 | 0 number | Number | 1 | | max-value | int16 | 20 | 0 number | Number | 1 | | status | enumeration | 21 | 0 number | Number | 1 | | conflict-information | grouping | 22 | 5 map | Object | | | conflict-status | enumeration | 23 | 0 number | Number | 1 | | conflict-cause | enumeration | 24 | 0 number | Number | 1 | | retry-timer | int32 | 25 | 0 number | Number | 1800 | | bytes-dropped | counter64 | 26 | 0 number | String | "1234" | | bps-dropped | counter64 | 27 | 0 number | String | "1234" | | pkts-dropped | counter64 | 28 | 0 number | String | "1234" | | pps-dropped | counter64 | 29 | 0 number | String | "1234" | | session-id | int32 | 30 | 0 number | Number | 65432 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | | | missing-hb-allowed | grouping | 32 | 5 map | Object | | | current-value | int16 | 33 | 0 number | Number | 10 | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.21 | | target-prefix | leaf-list | | 4 array | Array | | | | ip-prefix | 35 | 3 text string | String | | | client-domain-hash | leaf-list | | 4 array | Array | | | | binary | 36 | 2 byte string | String | "abcdf" | | alt-server | string | 37 | 3 text string | String | | | alt-server-record | list | 38 | 4 array | Array | | | addr | string | 39 | 3 text string | String | | | ttl | int32 | 40 | 0 number | Number | 1800 | | conflict-scope | grouping | 41 | 5 map | Object | | | acl-name | string | 42 | 3 text string | String | "aname" | | acl-type | string | 43 | 3 text string | String | "ipv4" | | config-interval | int32 | 44 | 0 number | Number | 11 | | mitigating-config | grouping | 45 | 5 map | Object | | | idle-config | grouping | 46 | 5 map | Object | | | request-nonce | binary | 47 | 2 byte string | String | "xxx" | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 | \----------------------+-------------+------+---------------+--------+------ ---/ Comments / suggestions? Regards Jon ------=_NextPart_000_094B_01D3801F.20DB97C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks for pointing me = to these references.

 

RFC7951

6.1.  Numeric = Types

 

   A value of = the "int8", "int16", "int32", = "uint8", "uint16", or

   = "uint32" type is represented as a JSON = number.

 

   A value of = the "int64", "uint64", or "decimal64" type = is represented

   as a JSON string whose content is = the lexical representation of the

   = corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 = of

   [RFC7950].

 

   For = example, if the type of the leaf "foo" in Section 5.1 = was

   "uint64" instead of = "uint8", the instance would have to be encoded = as

 

   = "foo": "123"

--

 

So, we now have a way of = handling int64/uint64 which should be used moving = forward.

 

However, my JSON = implementation (as well as many others I suspect) natively supports = decimal64, so does not necessarily need to display it as a lexical = representation string.  Do we follow RFC7951 here as = well?

 

I do not think that we = should be following the augmented JSON parameter naming in RFC7951 = “4. Names and Namespaces” otherwise we will start ending up = with JSON/CBOR parameter names such as = “ietf-dots-signal:mitigation-scope”.  If we do go with = this, then the CBOR mapping table will need to get extended to cover the = old, but some parameter name in different places.  = Comments?

 

As we are working with = YANG, JSON and CBOR interrelation , I still think we need a table = similar to below to aid implementers – referring as appropriate to = the different RFCs – no-one has full knowledge of all the evolving = RFCs.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 23 December 2017 = 07:06
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

We should just follow the CBOR = Encoding of Data Modeled with YANG defined in = https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON = Encoding of Data Modeled with YANG

defined in = https://tools.ietf.org/html/rfc7951.

 

-Tiru

 

From: Dots = [mailto:dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: Friday, December 22, 2017 10:41 PM
To: = dots@ietf.org
Subject: [Dots] Signal CBOR / JSON = Mapping

 

Hi = WG,

 

There are a lot of YANG parameters that we are using = that are defined as int64.  JSON only safely supports up to 53 bits = of precision.

 

RFC 7493 2.2 Numbers

 

   = An I-JSON sender cannot expect a receiver to treat an integer = whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range [-(2**53)+1, = (2**53)-1]) as an exact value.

 

   = For applications that require the exact interchange of numbers = with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values.  This requires = that the receiving program

   understand the intended semantic of the = value.  An example would be

   64-bit integers, even though modern = hardware can deal with them,

   because of the limited scope of = JavaScript numbers.

 

RFC7049 3.6 = Numbers

 

   CBOR-based protocols should take into = account that different language

   environments pose different restrictions = on the range and precision

   of numbers that are representable.  = For example, the JavaScript

   number system treats all numbers as = floating point, which may result

   in silent loss of precision in decoding = integers with more than 53

   significant bits.  A protocol that = uses numbers should define its

   expectations on the handling of = non-trivial numbers in decoders and

   receiving applications.

 

=3D=3D=3D=3D

 

An option is = to make all of these int64 decimal64 for the signal channel, but that = does not cover the 64 bit counters in the netmod-acl.  However, as = the netmod-acl counters are also fed back via the mitigate status, we do = not necessarily need to support the netmod-acl = counters.

 

If, however, we follow RFC 7493, in CBOR the data can = be passed across as 64 bits, and as the parameter is a CBOR mapping, we = can know how to encode / decode the JSON value as appropriate.  = However, RFC 7493 does not say whether this should be base64, base64url = or numeric string representation (i.e. “1234567890”). =  RFC7049 refers to bignum (major type 6, tag value 2 or 3) should = be encoded as base64url (4.1 Converting from CBOR to JSON) – but = int64 can be held in CBOR as type 0 or 1.

 

I prefer the = numeric string representation as it is humanly easy to read and easy to = convert into 64 bit integers.

 

If we take = this approach of using the parameter which is a CBOR mapping key to key = off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or = their possible new names of request-nonce and client-domain-hash) to = further minimize the actual number of bytes sent in a COAP = packet.

 

The CBOR mapping Table could then be extended to look = something like (but it is too wide I think)

 

/----------------------+-------------+------+--------------= -+--------+---------\

| Parameter = name       | YANG type   | CBOR = | CBOR major    | JSON   | = JSON    | 

|         &nbs= p;            = |            = | key  | = type          | = type   | Example |

|----------------------+-------------+------+--------------= -+--------+---------|

| = mitigation-scope     | grouping    = |   1  | 5 = map         | Object = |         |  =

| = scope           &n= bsp;    | list        = |   2  | 4 array       | = Array  |         |  =

| = mitigation-id        | = int32       |   3  | 0 = unsigned    | Number | 54321   |  =

| = acl-list        =      | = list        |   4  | 4 = array       | Array  = |         |  =

| = target-port-range    | = list        |   5  | 4 = array       | Array  = |         |  =

| = lower-port           | = port-number |   6  | 0 = number      | Number | 1111    = | 

| = upper-port           | = port-number |   7  | 0 = number      | Number | 1111    = | 

| = target-protocol      | leaf-list   = |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uint8       |   8  | 0 = number      | Number | = 6       |

| = target-fqdn          | = leaf-list   |      | 4 = array       | Array  = |         = |

|         &nbs= p;            | = domain-name |   9  | 3 text string | String | = "a.com" |

| = target-uri           | = leaf-list   |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uri         |  10  | 3 = text string | String |         = |

| = alias-name           | = leaf-list   |      | 4 = array       | Array  | =         |  =

| =             &= nbsp;        | = string      |  11  | 3 text string | = String | "web"   | 

| = lifetime           = ;  | int32       |  12  | 0 = number      | Number = |         |  =

| = attack-status        | enumeration = |  13  | 0 number      | Number | = 1       | 

| signal-config        = | grouping    |  14  | 5 = map         | Object = |         |  =

| = heartbeat-interval   | grouping    |  = 15  | 5 map         | = Object |         |  =

| = max-retransmit       | = grouping    |  16  | 5 = map         | Object = |         |  =

| = ack-timeout          | = grouping    |  17  | 5 = map         | Object = |         |  =

| = ack-random-factor    | grouping    |  = 18  | 5 map         | = Object |         |  =

| = min-value   =          | = int16       |  19  | 0 = number      | Number | = 1       | 

| = max-value          &nbs= p; | int16       |  20  | 0 = number      | Number | = 1       | 

| = status           &= nbsp;   | enumeration |  21  | 0 = number      | Number | = 1       | 

| conflict-information | grouping    = |  22  | 5 map         = | Object |         |  =

| = conflict-status      | enumeration |  = 23  | 0 number      | Number | = 1       | 

| conflict-cause       | = enumeration |  24  | 0 number      | = Number | 1       |  =

| = retry-timer          | = int32       |  25  | 0 = number      | Number | 1800    = | 

| = bytes-dropped        | = counter64   |  26  | 0 = number      | String | "1234"  = | 

| = bps-dropped          | = counter64   |  27  | 0 = number      | String | "1234"  = | 

| = pkts-dropped         | counter64 =   |  28  | 0 number      | = String | "1234"  | 

| = pps-dropped          | = counter64   |  29  | 0 = number      | String | "1234"  = | 

| = session-id           | = int32       |  30  | 0 = number      | Number | 65432   = | 

| = trigger-mitigation   | boolean     |  = 31  | 7 simple      | T / F  = |         |  =

| = missing-hb-allowed   | grouping    |  = 32  | 5 map         | = Object |         |  =

| = current-value        | = int16       |  33  | 0 = number      | Number | = 10      | 

| mitigation-start     | = decimal64   |  34  | 7 = FP          | Number | = 10.21   | 

| target-prefix        = | leaf-list   |      | 4 = array       | Array  = |         |  =

| =             &= nbsp;        | = ip-prefix   |  35  | 3 text string | String = |         |  =

| = client-domain-hash   | leaf-list   |  =     | 4 array       | = Array  |         = |

| =             &= nbsp;        | = binary      |  36  | 2 byte string | = String | "abcdf" |

| = alt-server           | = string      |  37  | 3 text string | = String |         |  =

| = alt-server-record    | = list        |  38  | 4 = array       | Array  = |         |  =

| = addr           &nb= sp;     | string      = |  39  | 3 text string | String = |         |  =

| = ttl           &nbs= p;      | = int32       |  40  | 0 = number      | Number | 1800    = | 

| = conflict-scope       | = grouping    |  41  | 5 = map         | Object = |         |  =

| = acl-name           = ;  | string      |  42  | 3 text = string | String | "aname" | 

| = acl-type           = ;  | string      |  43  | 3 text = string | String | "ipv4"  |  =

| = config-interval      | = int32       |  44  | 0 = number      | Number | = 11      | 

| mitigating-config    | = grouping    |  45  | 5 = map         | Object = |         |  =

| = idle-config          | = grouping    |  46  | 5 = map         | Object = |         |  =

| = request-nonce        | = binary      |  47  | 2 byte string | = String | "xxx"   | 

| min-value-decimal    | = decimal64   |  48  | 7 = FP          | Number | = 1.1     | 

| max-value-decimal    | = decimal64   |  49  | 7 = FP          | Number | = 1.1     | 

| current-value-decimal| decimal64   |  = 50  | 7 FP          | = Number | 1.1     | 

\----------------------+-------------+------+--------------= -+--------+---------/

 

 

Comments / = suggestions?

 

Regards

 

Jon

------=_NextPart_000_094B_01D3801F.20DB97C0-- From nobody Fri Dec 29 03:15:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4703B12D84F for ; Fri, 29 Dec 2017 03:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr1FvmaDdNHF for ; Fri, 29 Dec 2017 03:15:11 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8038124D68 for ; Fri, 29 Dec 2017 03:15:11 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eUscy-000430-Pm; Fri, 29 Dec 2017 11:15:04 +0000 From: "Jon Shallow" To: "kaname nishizuka" , References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> In-Reply-To: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> Date: Fri, 29 Dec 2017 11:15:07 -0000 Message-ID: <099601d38096$487c9410$d975bc30$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQLSq4q/0bL2TF/Kn5VRXUOjWNcfvgJYRDCAoUkKB1A= Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 11:15:14 -0000 Hi all, After thinking about this, I have added some additional comments inline [Jon1]. This response is applicable to more than just Kaname. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 28 December 2017 21:01 To: 'kaname nishizuka'; dots@ietf.org Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Hi Kaname, See inline [Jon]. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 28 December 2017 10:02 To: dots@ietf.org Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Hi, Last week, Jon and I did the second interoperability test based on the -13 version of the signal channel draft. We made significant improvements of each implementation. Several feedbacks to the WG have been made by Jon already. Based on the experience, I encountered the problems between CoAP libraries and the specification of the DOTS. 1. resource identification of GET methods. In signal channel spec, the target resource in GET method is identified in the BODY of the message, that is mitigation-id (and client-identifier). However, CoAP libraries, at least we investigated, only see the Request URI, so it cannot locate the resource because it doesn't see the BODY. So the question is, why does the DOTS spec use CoAP Body for resource identifier? [Jon] A very good question. I had just assumed that this was the way to do it, but had noted that this was not done when using HTTP etc. and so was different. See later comments Most of CoAP libraries only support request URI in CoAP GET/observe, which is the spec from RFC7252. https://tools.ietf.org/html/rfc7252 5.8.1.GET The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. [Jon] RFC 7252 states also 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to specify the target resource of a request to a CoAP origin server. [Jon] So it looks like the target resource should only be in Uri-Path and/or Uri-Query. [Jon] In my CoAP Library, I have to define each individual resource (it does a lookup against a hash of the complete Uri to find whether the resource is known or not), so, when say mitigation-id=2 is added, I need to register the resource .well-known/dots/v1/mitigate/migration-is=2 with an associated handler. This is not difficult to do, but potentially could consume a lot of DOTS server resources if many mitigations are active. [Jon] Doing it as a Query Option I think is my preference - Comments? [Jon] The same is true for GET signal configuration as well. [Jon1] I am now leaning towards doing it in the Uri-Path but still not sure. The CoAP layer responds with a 4.04 with my CoAP library if the resource (Uri-Path) is unknown. [Jon1] We need to define the order in the path - e.g. client-identifier (or request-none etc. if that is accepted) then mitigation-id, so that resources are built consistently from a mitigation request. [Jon1] However doing this means we also need to include PUT and DELETE with the resource specified in the Uri-Path. My library then runs into a chicken and egg situation with PUT - the PUT is defining the new resource, but as the resource is not defined (yet) in the CoAP layer, it gets rejected with a 4.04 in the CoAP layer (as mentioned above). The way around this is to use POST to create new mitigation requests (and will respond with appropriate Location-Path to give the new UI) and PUT if we are refreshing the resource. [Jon1] Thoughts? 2. Confirmable vs NonConfirmable at Mitigation Request A CoAP library (dustin/go-coap) stops listening right after sending out the NonConfirmable message because NonConfirmable messages do not require acknowledgements. [Jon] As there is a good chance during attack scenarios that responses may not be able to get back, it makes sense to me that these "GET mitigation" requests are non-confirmable. Certainly "PUT mitigation" needs to be thought of as a one way signal. There are times that the client has to run "blind" during attack scenarios. [Jon]If they were confirmable, then the request will get sent multiple times to the DOTS server - which could be handled by the server, but then the confirmable responses would retried whilst sending back to the DOTS client and eventually retry timeout. A large scale attack could swamp a DOTS server with all the yet to be confirmed confirmable responses. [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a non-confirmable request is expected to be handled as in:- If a request is sent in a Non-confirmable message, then the response is sent using a new Non-confirmable message, although the server may instead send a Confirmable message. This type of exchange is illustrated in Figure 6. Client Server | | | NON [0x7a11] | | GET /temperature | | (Token 0x74) | +----------------->| | | | NON [0x23bc] | | 2.05 Content | | (Token 0x74) | | "22.5 C" | |<-----------------+ | | Figure 6: A Request and a Response Carried in Non-confirmable Messages [Jon] So I would expect any CoAP library to support this non-confirmation mechanism by receiving a new non-confirmable message. It would be the responsibility of the DOTS layer to associate the Tokens together to handle the responses with the requests. [Jon] In addition, when Observe is enabled, the DOTS server will continue to generate non-confirmable messages with the same Token. Again, the DOTS client will need to know what to do with the Token (which could be to update things, or to send a RST if no more packets with the same Token should be sent. The spec of Confirmable message already have the retransmission mechanism, so using Confirmable message is an easier way to notice that the message has been lost during the attack time. [Jon] The DOTS client will know something is wrong as it will be seeing heartbeat issues. I'm afraid I'm missing some previous discussions we made on the ML and at the WG meeting, but we have a problem with the CoAP library regarding this spec. * At the -08 version of the signal channel draft, this change was made: DOTS mitigation request/response are marked as non-confirmable messages. thank you, Kaname _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Fri Dec 29 07:50:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C50127871 for ; Fri, 29 Dec 2017 07:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1f6wY2XRpcs for ; Fri, 29 Dec 2017 07:50:43 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D411D1241F8 for ; Fri, 29 Dec 2017 07:50:42 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eUwvh-00049s-9D for ietf-supjps-dots@ietf.org; Fri, 29 Dec 2017 15:50:41 +0000 From: "Jon Shallow" To: Date: Fri, 29 Dec 2017 15:50:43 -0000 Message-ID: <09aa01d380bc$c8e5d9b0$5ab18d10$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09AB_01D380BC.C8E84AB0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdOAvMIC7WALjv/0TF6u38Ag24OGtA== Archived-At: Subject: [Dots] Filter usage X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 15:50:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09AB_01D380BC.C8E84AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, Should a mitigation request be able to define which filters to use? This has been raised in the past but there was no real closure - but other related things did get fixed. An ACL can comprise of a src/dest IP prefix, port etc. and an action - drop, allow or rate-limit. A Filter definition can contain multiple ACLs - the ACLs are now orderable. An individual DOTS client can now define multiple Filters - the Filters are now orderable. However, today, when a mitigation request comes into the DOTS server, all the Filter rules associated with a DOTS client are taken and passed over to a DOTS mitigation (how etc. out of scope of DOTS, as well as what the mitigator does with them is out of scope). The primary use of the Filters would be for White / Black listed IPs (the src IP prefix and action defined in an ACL) and there is an implied assumption that the DOTS mitigator would only apply these White / Black lists to the IPs that are to be mitigated (i.e. an implicit dest IP prefix is defined / added in). These White / Black lists would tend to be fairly static and normally would be updated during peace time. However, by using draft-ietf-netconf-acl-model as the basis for these filters adds in the potential for intelligent DOTS clients to come up with specific ACLs and hence filters which could be used as hints for the DOTS mitigator. The different filters can easily be created / deleted during peace time - but if an attack is ongoing, a DOTS client may not be able to update the current set of Filters. This therefore potentially limits potential use of special filters (which potentially needing updating as an attack morphs) matching the current attack characteristics. There is one camp that thinks that Filters (other than black/white lists) should not be supported (for a variety of reasons - e.g. DOTS is not to reproduce FlowSpec, complexity and numbers of ACLs will overwhelm the infrastructure etc.) as well as the other camp who like the possibility of flexibility, and in addition say the numbers of ACLs will not be that much different from the black/white list requirements. To provide this full flexibility, a mitigation request over the signal channel needs to be able to specify an array of Filters (in the same way that an array of Alias-names is specified) to use - thereby being able to select out of a pre-attack configured set Filters which ones to use. This would be an update the signal mitigation requirements. Comments welcome. Regards Jon ------=_NextPart_000_09AB_01D380BC.C8E84AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

Should a mitigation request be able to define which = filters to use?

 

This has = been raised in the past but there was no real closure – but other = related things did get fixed.

 

An ACL can = comprise of a src/dest IP prefix, port etc. and an action – drop, = allow or rate-limit.

A Filter = definition can contain multiple ACLs – the ACLs are now = orderable.

An individual DOTS client = can now define multiple Filters – the Filters are now = orderable.

 

However, today, when a mitigation request comes into = the DOTS server, all the Filter rules associated with a DOTS client are = taken and passed over to a DOTS mitigation (how etc. out of scope of = DOTS, as well as what the mitigator does with them is out of = scope).

 

The primary use of the Filters would be for White / = Black listed IPs (the src IP prefix and action defined in an ACL) and = there is an implied assumption that the DOTS mitigator would only apply = these White / Black lists to the IPs that are to be mitigated (i.e. an = implicit dest IP prefix is defined / added in).  These White / = Black lists would tend to be fairly static and normally would be updated = during peace time.

 

However, by = using draft-ietf-netconf-acl-model as the basis for these filters adds = in the potential for intelligent DOTS clients to come up with specific = ACLs and hence filters which could be used as hints for the DOTS = mitigator.  The different filters can easily be created / deleted = during peace time – but if an attack is ongoing, a DOTS client may = not be able to update the current set of Filters.  This therefore = potentially limits potential use of special filters (which potentially = needing updating as an attack morphs) matching the current attack = characteristics.

 

There is one = camp that thinks that Filters (other than black/white lists) should not = be supported (for a variety of reasons – e.g. DOTS is not to = reproduce FlowSpec, complexity and numbers of ACLs will overwhelm the = infrastructure etc.) as well as the other camp who like the possibility = of flexibility, and in addition say the numbers of ACLs will not be that = much different from the black/white list requirements.

 

To provide = this full flexibility, a mitigation request over the signal channel = needs to be able to specify an array of Filters (in the same way that an = array of Alias-names is specified) to use – thereby being able to = select out of a pre-attack configured set Filters which ones to = use.  This would be an update the signal mitigation = requirements.

 

Comments welcome.

 

Regards

 

Jon

------=_NextPart_000_09AB_01D380BC.C8E84AB0-- From nobody Fri Dec 29 08:17:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE6A128959 for ; Fri, 29 Dec 2017 08:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRknHBvSK2zk for ; Fri, 29 Dec 2017 08:17:01 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2702112704A for ; Fri, 29 Dec 2017 08:17:01 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eUxL9-0004Aq-MB for ietf-supjps-dots@ietf.org; Fri, 29 Dec 2017 16:16:59 +0000 From: "Jon Shallow" To: Date: Fri, 29 Dec 2017 16:17:01 -0000 Message-ID: <09c301d380c0$75b1d060$61157120$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09C4_01D380C0.75B1D060" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdOAwHWSK0qslD93TEaNhsHenXcqSQ== Archived-At: Subject: [Dots] source-ip-prefix in signal mitigation request. X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 16:17:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09C4_01D380C0.75B1D060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, Currently, the signal spec only allows for target-* definitions with the option for Vendor-Specific CBOR Key values. We have already seen from ietf-100 interoperability tests that there is potentially already one Vendor-Specific definition of source-ip-prefix. Does it make sense to have "source-ip-prefix" as a standard, optional parameter? There will be a limitation of number of source IPs that can be defined due to packet MTU. The mitigation overlapping rules (e.g. same "target-ip") where the highest "mitigation-id" is the active rule will also constrain the number of source IPs. It does however give the flexibility of, say, temporarily black-listing certain IPs that an intelligent DOTS client has determined to be the most active in an attack. Comments? Regards Jon ------=_NextPart_000_09C4_01D380C0.75B1D060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

Currently, the signal spec only allows for target-* = definitions with the option for Vendor-Specific CBOR Key = values.

 

We have already seen from ietf-100 interoperability = tests that there is potentially already one Vendor-Specific definition = of source-ip-prefix.

 

Does it make = sense to have “source-ip-prefix” as a standard, optional = parameter?

 

There will be a limitation of number of source IPs = that can be defined due to packet MTU.

 

The = mitigation overlapping rules (e.g. same “target-ip”) where = the highest “mitigation-id” is the active rule will also = constrain the number of source IPs.

 

It does = however give the flexibility of, say, temporarily black-listing certain = IPs that an intelligent DOTS client has determined to be the most active = in an attack.

 

Comments?

 

Regards

 

Jon

------=_NextPart_000_09C4_01D380C0.75B1D060-- From nobody Sat Dec 30 03:27:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F701241F5 for ; Sat, 30 Dec 2017 03:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCq4-xgKR3Wx for ; Sat, 30 Dec 2017 03:27:23 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EB1124207 for ; Sat, 30 Dec 2017 03:27:23 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eVFIO-0004ii-Mh for ietf-supjps-dots@ietf.org; Sat, 30 Dec 2017 11:27:20 +0000 From: "Jon Shallow" To: Date: Sat, 30 Dec 2017 11:27:23 -0000 Message-ID: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A13_01D38161.299EF350" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqg== Archived-At: Subject: [Dots] Using SNI X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 11:27:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A13_01D38161.299EF350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.). Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work. I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services. As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello. Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port. Thoughts / comments? Regards Jon ------=_NextPart_000_0A13_01D38161.299EF350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

When providing a DOTS server data channel service in = my environment, this shares the same ip / port which also provides other = services (e.g. GUI / REST server etc.).  Even if the Root Discovery = points to another IP and or port for the actual data channel activity, = the TLS exchanges for the Root Discovery have to correctly work.  I = suspect that I am not the only DOTS vendor who will have this type of = requirement of a single IP providing multiple TLS = services.

 

As DOTS requires mutual authentication, this is a = different security requirement than required by the GUI environment = (DOTS requires client cert to be presented, GUI does not and providing = certificates to every GUI client is not a practical = option).

 

This can be handled by using SNI by using 2 different = FQDNs and requiring the DOTS client to include the DOTS specific FQDN in = the TLS Client Hello.  Whether the GUI client does or does not = (likely does with modern browsers) include a SNI FQDN when connecting to = the non DOTS FQDN does not really matter – for DOTS it is = recognizing the DOTS specific FQDN and setting up the TLS as = appropriate.

 

To make sure interoperability between DOTS vendors, I = would like to see something like added to the data channel spec = “DOTS clients MUST include the DOTS server FQDN in the TLS Client = Hello packet by using Server Name Indication (SNI) RFC = 3546”.

 

In addition, I think that this would be a good idea as = well for the signal draft – thereby giving DOTS vendors the = opportunity to host multiple DOTS servers (likely to be different = security requirements for their different client) on a single IP / = port.

 

Thoughts / comments?

 

Regards

 

Jon

------=_NextPart_000_0A13_01D38161.299EF350--