Subject: [Dots] WGLC for draft-dots-use-cases-19

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 6 Aug 2019 09:26:06 +0300

Hi,

this message starts a short WGLC for draft-ietf-dots-use-cases-19 to confirm
the WG consensus regarding the latest addition of a new use case to the draft.
The WGLS will last one week and will end on Tuesday, 13 August.

Regards,
Frank & Valery.

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 06:48:13 +0000

Hi Chairs, all, 

I support advancing this draft. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Valery Smyslov
> Envoyé : mardi 6 août 2019 08:26
> À : [email-masked]
> Cc : Xialiang (Frank, Network Standard & Patent Dept)
> Objet : [Dots] WGLC for draft-dots-use-cases-19
> 
> Hi,
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 06:52:24 +0000

The security implications of the new use case need to be discussed in the draft, please see https://mailarchive.ietf.org/arch/msg/dots/tb-1ojJ6TmSmRUci6JoUeD-gB1Y 

Cheers,
-Tiru

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Valery Smyslov
> Sent: Tuesday, August 6, 2019 11:56 AM
> To: [email-masked]
> Cc: Xialiang (Frank, Network Standard & Patent Dept)
> <[email-masked]>
> Subject: [Dots] WGLC for draft-dots-use-cases-19
> 
> 
> 
> Hi,
>

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 07:20:28 +0000

Hi Tiru, 

The NEW text indicates the following: 

==
   In addition to the above DDoS Orchestration, the selected DDoS
   mitigation systems can return back a mitigation request to the
   orchestrator as an offloading. 
                     ^^^^^^^^^^^
   ....
   the DDoS mitigation system can send mitigation requests
   with additional hints such as its blocked traffic information to the
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^          
   orchestrator.
==

Which means that the DMS is blocking that traffic based on "some" information. That same information is passed to an orchestrator so that it can filter the traffic. What changes is ** how/where ** filters are installed. 

Like the interface with a mitigator, the interface between the controller and underlying routers is out of scope. 

>From a DOTS perspective, the information supplied by the DMS to an Orchestrator is considered as "additional hints" which is adhering to RFC8612:

==
   GEN-004  Mitigation Hinting: DOTS clients may have access to attack
      details that can be used to inform mitigation techniques.  Example
      attack details might include locally collected fingerprints for an
      on-going attack, or anticipated or active attack focal points
      based on other threat intelligence.  DOTS clients MAY send
      mitigation hints derived from attack details to DOTS servers, with
      the full understanding that the DOTS server MAY ignore mitigation
      hints.
==   

I don't think there are new security considerations induced by the NEW text.  

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : mardi 6 août 2019 08:52
> À : Valery Smyslov; [email-masked]
> Objet : Re: [Dots] WGLC for draft-dots-use-cases-19
> 
> The security implications of the new use case need to be discussed in the
> draft, please see https://mailarchive.ietf.org/arch/msg/dots/tb-
> 1ojJ6TmSmRUci6JoUeD-gB1Y
> 
> Cheers,
> -Tiru
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 08:14:06 +0000

Hi Med,

No, the orchestrator is not ignoring the mitigation hints. It is sending filtering rules to block or rate-limit traffic to routers (last but one line in the new paragraph). The adverse impact is legitimate users whose IP addresses were spoofed 
cannot access the services of the target server.  

Cheers,
-Tiru

> From: [email-masked]
> <[email-masked]>
> Sent: Tuesday, August 6, 2019 12:50 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Valery Smyslov
> <[email-masked]>; [email-masked]
> Subject: RE: [Dots] WGLC for draft-dots-use-cases-19
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Tiru,
> 
> Which means that the DMS is blocking that traffic based on "some"
> information. That same information is passed to an orchestrator so that it can
> filter the traffic. What changes is ** how/where ** filters are installed.
> 
> From a DOTS perspective, the information supplied by the DMS to an
> Orchestrator is considered as "additional hints" which is adhering to RFC8612:
> 
> ==
> > De : Dots [mailto:[email-masked]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : mardi 6 août 2019 08:52 À : Valery
> > Smyslov; [email-masked] Cc : Xialiang (Frank, Network Standard & Patent
> > Dept) Objet : Re: [Dots] WGLC for draft-dots-use-cases-19
> >
> > The security implications of the new use case need to be discussed in
> > the draft, please see https://mailarchive.ietf.org/arch/msg/dots/tb-
> > 1ojJ6TmSmRUci6JoUeD-gB1Y
> >
> > Cheers,
> > -Tiru
> >

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 6 Aug 2019 11:19:47 +0300

On Tue, Aug 6, 2019, 11:15 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> The adverse impact is legitimate users whose IP addresses were spoofed

This must never never happen in production systems.  You do not block an IP
address if you haven't verified that it's not spoofed.  DOTS has nothing to
do with this.

--
Töma

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 08:30:29 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : mardi 6 août 2019 10:14
> À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [email-masked]
> Objet : RE: [Dots] WGLC for draft-dots-use-cases-19
> 
> Hi Med,
> 
> No, the orchestrator is not ignoring the mitigation hints.

[Med] Why? The text is clear the orchestrator acts as DOTS server. As such, it can ignore/accept hints.  

 It is sending
> filtering rules to block or rate-limit traffic to routers (last but one
> line in the new paragraph).

[Med] Yes. That filtering rule is that would be applied by the DMS if it has sufficient resources. 

 The adverse impact is legitimate users whose
> IP addresses were spoofed

[Med] This is a check at the DMS side. This check applies independently of ** where ** the filters are applied. This is not specific to this NEW text. 

> > Like the interface with a mitigator, the interface between the
> controller and
> > underlying routers is out of scope.
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 09:14:32 +0000

> Sent: Tuesday, August 6, 2019 2:00 PM
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [email-masked] Cc :
> > Xialiang (Frank, Network Standard & Patent Dept) Objet : RE: [Dots]
> > WGLC for draft-dots-use-cases-19
> >
> > Hi Med,
> >
> > filtering rules to block or rate-limit traffic to routers (last but
> > one line in the new paragraph).
> 
> [Med] This is a check at the DMS side. This check applies independently of **
> where ** the filters are applied. This is not specific to this NEW text.

If the orchestrator is sending filtering rules to block traffic, checks are required to ensure spoofed IP address are not conveyed by the DMS. If the orchestrator delegates the mitigation to a separate domain (recursive signaling), 
the attack information provided by DMS can include spoofed IP addresses (so the new mitigator in the separate domain learns the attack traffic is coming from spoofed IP addresses).

-Tiru

> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Tiru,
> > >
> > > information. That same information is passed to an orchestrator so
> > > that
> > it can
> > > Orchestrator is considered as "additional hints" which is adhering
> > > to
> > RFC8612:
> > >
> > > ==
> > > I don't think there are new security considerations induced by the
> > > NEW
> > text.
> > >
> > > Cheers,
> > > Med
> > >
> > > > The security implications of the new use case need to be discussed
> > > > in the draft, please see
> > > > https://mailarchive.ietf.org/arch/msg/dots/tb-
> > > > 1ojJ6TmSmRUci6JoUeD-gB1Y
> > > >
> > > > Cheers,
> > > > -Tiru
> > > >
> > > > > this message starts a short WGLC for
> > > > > draft-ietf-dots-use-cases-19 to
> > > > confirm

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 09:19:02 +0000

From: Dots <[email-masked]> On Behalf Of Töma Gavrichenkov
Sent: Tuesday, August 6, 2019 1:50 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>; Valery Smyslov <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] WGLC for draft-dots-use-cases-19

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
On Tue, Aug 6, 2019, 11:15 AM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
The adverse impact is legitimate users whose IP addresses were spoofed
cannot access the services of the target server.

This must never never happen in production systems.  You do not block an IP address if you haven't verified that it's not spoofed.  DOTS has nothing to do with this.

[TR] My point is DOTS can be used to convey the spoofed IP addresses, and the attack information can either be used to delegate the mitigation to a separate domain or filter traffic (e.g. using ACLs). For the latter case, the new paragraph should clarify the attack information of spoofed IP addresses will not be used by the orchestrator to filter traffic.

-Tiru

--
Töma

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 09:19:57 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 6 août 2019 11:15
> > [Med] Why? The text is clear the orchestrator acts as DOTS server. As
> such, it
> > can ignore/accept hints.
> >
> >  It is sending
> > [Med] Yes. That filtering rule is that would be applied by the DMS if it
> has
> > sufficient resources.
> >
> If the orchestrator is sending filtering rules to block traffic, checks
> are required to ensure spoofed IP address are not conveyed by the DMS.

[Med] Yes, but the current text describes the case where the DMS supplies "its blocked traffic information": 

So, the DMS has already done that check. 

 If
> the orchestrator delegates the mitigation to a separate domain (recursive
> signaling),
> the attack information provided by DMS can include spoofed IP addresses
> (so the new mitigator in the separate domain learns the attack traffic is
> coming from spoofed IP addresses).

[Med] This is not specific to this case, but applies each time there is recursive signaling.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 09:29:06 +0000

> Sent: Tuesday, August 6, 2019 2:50 PM
> > > > Xialiang (Frank, Network Standard & Patent Dept) Objet : RE:
> > > > [Dots] WGLC for draft-dots-use-cases-19
> > > >
> > > > Hi Med,
> > > >
> > > > filtering rules to block or rate-limit traffic to routers (last
> > > > but one line in the new paragraph).
> > >
> > > [Med] This is a check at the DMS side. This check applies
> > > independently
> > of **
> > If the orchestrator is sending filtering rules to block traffic,
> > checks are required to ensure spoofed IP address are not conveyed by the
> DMS.
> 

The blocked traffic information will include attack traffic from both spoofed and attacker IP addresses.

> 
>  If
> > the orchestrator delegates the mitigation to a separate domain
> > (recursive signaling), the attack information provided by DMS can
> > include spoofed IP addresses (so the new mitigator in the separate
> > domain learns the attack traffic is coming from spoofed IP addresses).
> 

My comment is to using the attack information of spoofed IP addresses to filter traffic would penalize legitimate users, and the text is not clear me. I suggest adding a line for clarity, DMS may supply both spoofed and attacker IP addresses in the attack information to the orchestrator. The orchestrator will only use the non-spoofed IP addresses to enforce filtering rules on routers.

-Tiru

> > > > > This email originated from outside of the organization. Do not
> > > > > click
> > > > links or
> > > > >    with additional hints such as its blocked traffic information
> > > > > to
> > the
> > > > > information. That same information is passed to an orchestrator
> > > > > so that
> > > > it can
> > > > > From a DOTS perspective, the information supplied by the DMS to
> > > > > an Orchestrator is considered as "additional hints" which is
> > > > > adhering to
> > > > RFC8612:
> > > > >
> > > > > ==
> > > > >       attack details might include locally collected
> > > > > fingerprints
> > for an
> > > > >       mitigation hints derived from attack details to DOTS
> > > > > servers,
> > with
> > > > > I don't think there are new security considerations induced by
> > > > > the NEW
> > > > text.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > The security implications of the new use case need to be
> > > > > > discussed in the draft, please see

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 09:44:45 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : mardi 6 août 2019 11:29
> > [Med] Yes, but the current text describes the case where the DMS
> supplies
> > "its blocked traffic information":
> >

[Med] If you are saying that there is an issue if the DMS does not check, you are right. But, again, this is not specific to the NEW text. This is a general problem (that is outside DOTS, BTW). 

> > [Med] This is not specific to this case, but applies each time there is
> recursive
> > signaling.
> 
> My comment is to using the attack information of spoofed IP addresses to
> filter traffic would penalize legitimate users, and the text is not clear
> me. I suggest adding a line for clarity, DMS may supply both spoofed and
> attacker IP addresses in the attack information to the orchestrator. The
> orchestrator will only use the non-spoofed IP addresses to enforce
> filtering rules on routers.

[Med] I was assuming this is already done by the DMS to generate "its blocked traffic information", but if you prefer the text to be explicit, it will need to be generic: 

the check is not specific to the NEW text but applies also in the general DMS case (without offloading).

---

From: H Y <[email-masked]>
Date: Tue, 6 Aug 2019 18:45:36 +0900

Hi,

>   with additional hints such as its blocked traffic information to the
[Yuhei]
+1. IMO, it's no problem with sending such hints because the DMS has
already blocked the traffic.

Thanks,
Yuhei

--
----------------------------------
Yuuhei HAYASHI
08065300884
[email-masked]
[email-masked]
----------------------------------

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 11:52:23 +0000

> Sent: Tuesday, August 6, 2019 3:15 PM
> > > > > > Envoyé : mardi 6 août 2019 10:14 À : BOUCADAIR Mohamed
> > > > > > TGI/OLN; Valery Smyslov; [email-masked] Cc :
> > > > > > filtering rules to block or rate-limit traffic to routers
> > > > > > (last but one line in the new paragraph).
> > > > >
> > > > > where ** the filters are applied. This is not specific to this
> > > > > NEW
> > text.
> > > >
> > > > checks are required to ensure spoofed IP address are not conveyed
> > > > by
> > the
> > > DMS.
> > >
> [Med] If you are saying that there is an issue if the DMS does not check, you
> are right. But, again, this is not specific to the NEW text. This is a general
> problem (that is outside DOTS, BTW).

No, DMS will anyway check and try not block legitimate traffic from users whose IP addresses have been spoofed.

> > My comment is to using the attack information of spoofed IP addresses
> > to filter traffic would penalize legitimate users, and the text is not
> > clear me. I suggest adding a line for clarity, DMS may supply both
> > spoofed and attacker IP addresses in the attack information to the
> > orchestrator. The orchestrator will only use the non-spoofed IP
> > addresses to enforce filtering rules on routers.
> 
> [Med] I was assuming this is already done by the DMS to generate "its
> blocked traffic information", but if you prefer the text to be explicit, it will
> need to be generic:
> 

When DMS generates the attack traffic information it should include both spoofed and attacker IP addresses (tagged with whether the IP address is spoofed or not). If the orchestrator is delegating the mitigation to a separate domain, it can propagate the attack information so the mitigator in the separate domain has knowledge that the attacker is using spoofed IP addresses and the mitigator can optionally use the attack information to determine the mitigation strategy. However If orchestrator is enforcing filtering rules on routers, it should create the black-list rules based on the non-spoofed attacker IP address and not use the spoofed victim IP addresses.

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 12:16:16 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 6 août 2019 13:52
> > > > > > [Med] Why? The text is clear the orchestrator acts as DOTS
> server.
> > > > > > As
> > > > > such, it
> > > > > > can ignore/accept hints.
> > > > > >
> > > > > >  It is sending

[Med] What I'm saying is that the DMS will then follow the same logic when providing the hints to the orchestrator. 

> > the check is not specific to the NEW text but applies also in the
> general DMS
> > case (without offloading).
> 
> When DMS generates the attack traffic information it should include both
> spoofed and attacker IP addresses (tagged with whether the IP address is
> spoofed or not). 

[Med] Why it should not check?   

If the orchestrator is delegating the mitigation to a
> separate domain, it can propagate the attack information so the mitigator
> in the separate domain has knowledge that the attacker is using spoofed IP
> addresses and the mitigator can optionally use the attack information to
> determine the mitigation strategy.

[Med] The recursive case is not covered in the current text. I don't think we need to elaborate on this further. 

 However If orchestrator is enforcing
> filtering rules on routers, it should create the black-list rules based on
> the non-spoofed attacker IP address and not use the spoofed victim IP
> addresses.
> 

[Med] Agree. Whether the check is done at the orchestrator or by the DMS, is not a new concern. The DMS has to proceed with these checks, anyway. I fail to see what is NEW and SPECIFIC to the offload scenario.

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 6 Aug 2019 13:20:41 +0100

I had an interesting one a couple of years back.

Attackers were hitting 8.8.8.8 with a lot of DNS queries, spoofing the victim's IP address.  As there were a lot of unsolicited responses coming from 8.8.8.8 it was deduced that there was a reflective attack in progress against the victim's IP address and 8.8.8.8 was black-listed (fortunately close to the victim's IP address).

Unfortunately the victim IP was relying on 8.8.8.8 for its DNS services and so was effectively taken offline - but slowly - as DNS caches timed out for all the devices behind the corporate gateway (victim's IP).  Things were partially working for some time...

So usage of 8.8.8.8 was being both spoofed and genuine.

Top talkers is a hint and only that - deciding what to do with it needs to be done with care.  DOTS is a mechanism for passing information, requesting action etc. but does not do the ultimate mitigation.

Regards

Jon

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 6 Aug 2019 15:29:21 +0300

Peace,

> spoofed and attacker IP addresses (tagged with whether the IP address is

I must say I don't understand what is the reason behind collecting spoofed
IP addresses.  That is, especially with IPv6, an overly massive amount of
data to store and transmit, and in 99,999% of cases it has exactly zero
value for either attack mitigation or threat intel, b/c you may just
generate that from your own /dev/urandom, it'd be of the same quality.

--
Töma

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 12:30:59 +0000

> Sent: Tuesday, August 6, 2019 5:46 PM
> > > > > > Envoyé : mardi 6 août 2019 11:15 À : BOUCADAIR Mohamed
> > > > > > > This email originated from outside of the organization. Do
> > > > > > > not click
> > > > > > links or
> > > > > > > open attachments unless you recognize the sender and know
> > > > > > > the content is safe.
> > > > > > >
> > > > > > > Re-,
> > > > > > >
> > > > > > > Please see inline.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy
> > > > > > > where ** the filters are applied. This is not specific to
> > > > > > > this NEW
> > > > text.
> > > > > >
> > > > > > If the orchestrator is sending filtering rules to block
> > > > > > traffic, checks are required to ensure spoofed IP address are
> > > > > > not conveyed by
> > > > the
> > > > > DMS.
> > > > >
> > > are right. But, again, this is not specific to the NEW text. This is
> > > a
> > general
> > No, DMS will anyway check and try not block legitimate traffic from
> > users whose IP addresses have been spoofed.
> >
> 

No, the hints should include both spoofed and non-spoofed IP addresses used to attack the target. 

> > > > > > (recursive signaling), the attack information provided by DMS
> > > > > > can include spoofed IP addresses (so the new mitigator in the
> > > > > > separate domain learns the attack traffic is coming from
> > > > > > spoofed IP
> > addresses).
> > > > >
> > > > My comment is to using the attack information of spoofed IP
> > > > addresses to filter traffic would penalize legitimate users, and
> > > > the text is not clear me. I suggest adding a line for clarity, DMS
> > > > may supply both spoofed and attacker IP addresses in the attack
> > > > information to the orchestrator. The orchestrator will only use
> > > > the non-spoofed IP addresses to enforce filtering rules on routers.
> > >
> > > [Med] I was assuming this is already done by the DMS to generate
> > > "its blocked traffic information", but if you prefer the text to be
> > > explicit,
> > it will
> > > need to be generic:
> > >
> > When DMS generates the attack traffic information it should include
> > both spoofed and attacker IP addresses (tagged with whether the IP
> > address is spoofed or not).
> 

It checks and includes both type of IP addresses. 

> > separate domain, it can propagate the attack information so the
> > mitigator in the separate domain has knowledge that the attacker is
> > using spoofed IP addresses and the mitigator can optionally use the
> > attack information to determine the mitigation strategy.
> 

I don't understand why recursive case should be excluded in the current text ?

> > filtering rules on routers, it should create the black-list rules
> > based on the non-spoofed attacker IP address and not use the spoofed
> > victim IP addresses.
> >
> 
> [Med] Agree. Whether the check is done at the orchestrator or by the DMS,
> is not a new concern. The DMS has to proceed with these checks, anyway. I
> fail to see what is NEW and SPECIFIC to the offload scenario.

In this case the check has to be done by orchestrator when enforcing black-list rules not to penalize the spoofed victim IP addresses and should be discussed in the new use case. I don't see any other use case in the specification discussing offload scenario with propagating the attack information and I recommend updating the text discussing the above scenarios.
 
Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 12:34:22 +0000

> From: Jon Shallow <[email-masked]>
> Sent: Tuesday, August 6, 2019 5:51 PM
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Attackers were hitting 8.8.8.8 with a lot of DNS queries, spoofing the victim's
> IP address.  As there were a lot of unsolicited responses coming from 8.8.8.8
> it was deduced that there was a reflective attack in progress against the
> victim's IP address and 8.8.8.8 was black-listed (fortunately close to the
> victim's IP address).
> 
> Unfortunately the victim IP was relying on 8.8.8.8 for its DNS services and so
> was effectively taken offline - but slowly - as DNS caches timed out for all the
> devices behind the corporate gateway (victim's IP).  Things were partially
> working for some time...
> 
> Top talkers is a hint and only that - deciding what to do with it needs to be
> done with care.  DOTS is a mechanism for passing information, requesting
> action etc. but does not do the ultimate mitigation.

Agreed, I am only suggesting to explain this scenario in detail to avoid penalizing legitimate users, see https://tools.ietf.org/html/rfc3552#section-5

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 12:52:34 +0000

From: Töma Gavrichenkov <[email-masked]>
Sent: Tuesday, August 6, 2019 5:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]; Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
Subject: Re: [Dots] WGLC for draft-dots-use-cases-19

________________________________
Peace,
On Tue, Aug 6, 2019, 2:52 PM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
When DMS generates the attack traffic information it should include both spoofed and attacker IP addresses (tagged with whether the IP address is spoofed or not).

I must say I don't understand what is the reason behind collecting spoofed IP addresses.  That is, especially with IPv6, an overly massive amount of data to store and transmit, and in 99,999% of cases it has exactly zero value for either attack mitigation or threat intel, b/c you may just generate that from your own /dev/urandom, it'd be of the same quality.

I am referring to reflection attacks (e.g. DNS amplification attack). The other attack could be where the surveillance IP camera's IP address is spoofed, traffic from this IP address is black-listed and it no longer can send feeds to its server (and the attacker can successfully launch a physical attack (e.g. home burglary)). The problem is with the following lines in the offload scenario:

   When the DDoS attack becomes severe
   and the DDoS mitigation system's utilization rate reaches its maximum
   capacity, the DDoS mitigation system can send mitigation requests
   with additional hints such as its blocked traffic information to the
   orchestrator.  Then the orchestrator can take further actions like
   requesting forwarding nodes such as routers to filter the traffic.

-Tiru

--
Töma

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 12:53:14 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 6 août 2019 14:31
> > [Med] What I'm saying is that the DMS will then follow the same logic
> when
> > providing the hints to the orchestrator.
> 

[Med] Why? A DMS may decide to offload only filtering rules its checked. 

Even if we assume that the check is at the orchestrator side, this is not a new threat vector. 

> It checks and includes both type of IP addresses.

[Med] Why it has to include both if it has done the check? 

> > [Med] The recursive case is not covered in the current text. I don't
> think we
> > need to elaborate on this further.
> 

[Med] Because the use-case draft does not cover this: It only covers the case of an orchestrator talking to local routers. 

> In this case the check has to be done by orchestrator when enforcing
> black-list rules not to penalize the spoofed victim IP addresses and
> should be discussed in the new use case.

[Med] This requirement has to be followed by the DMS, anyway. This is not a new issue, Tiru.  

 I don't see any other use case in
> the specification discussing offload scenario with propagating the attack
> information and I recommend updating the text discussing the above
> scenarios.

[Med] We don't have a similar text for the DMS case because mitigation is out of scope. I'm expecting to follow the some rationale for the offload.

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 12:55:23 +0000

Thanks, Jon. 

Fully agree with your last sentence. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : mardi 6 août 2019 14:21
> À : 'Konda, Tirumaleswar Reddy'; [email-masked]; BOUCADAIR
> Mohamed TGI/OLN; [email-masked]; [email-masked]
> Attackers were hitting 8.8.8.8 with a lot of DNS queries, spoofing the
> victim's IP address.  As there were a lot of unsolicited responses coming
> from 8.8.8.8 it was deduced that there was a reflective attack in progress
> against the victim's IP address and 8.8.8.8 was black-listed (fortunately
> close to the victim's IP address).
> 
> Unfortunately the victim IP was relying on 8.8.8.8 for its DNS services
> and so was effectively taken offline - but slowly - as DNS caches timed
> out for all the devices behind the corporate gateway (victim's IP).
> Things were partially working for some time...
> 
> Top talkers is a hint and only that - deciding what to do with it needs to
> be done with care.  DOTS is a mechanism for passing information,
> requesting action etc. but does not do the ultimate mitigation.
> 
> Regards
> 
> Jon
>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 6 Aug 2019 16:05:24 +0300

On Tue, Aug 6, 2019 at 3:52 PM Konda, Tirumaleswar Reddy
<[email-masked]> wrote:
>> I must say I don't understand what is the reason
>> behind collecting spoofed IP addresses.
>
> I am referring to reflection attacks
> (e.g. DNS amplification attack).

Especially under those attacks you must not drop traffic based on
source IP addresses in it.  Otherwise you will fall directly into a
lovely crafted trap when the attacker starts to generate traffic with
source IP addresses of your potential users.

But anyway, DOTS is not about attack mitigation techniques, it's just
a signalling channel.  How exactly the mitigation is being carried out
by either side of the channel is out of scope of the WG.

> The other attack could be where the surveillance
> IP camera's IP address is spoofed, traffic from this
> IP address is black-listed and it no longer can send
> feeds to its server

Yes, this is in particular why you must not take into account any data
you haven't verified, including (but not limited to) a source IP
address before a handshake is completed successfully.

--
Töma

---

From: H Y <[email-masked]>
Date: Tue, 6 Aug 2019 22:06:10 +0900

Hi

Please see inline.

> [Med] Agree. Whether the check is done at the orchestrator or by the DMS, is not a new concern. The DMS has to proceed with these checks, anyway. I fail to see what is NEW and SPECIFIC to the offlo…
[Yuhei]
The NEW point of the offload scenario is that DMS has DOTS client
function in DDoS orchestration usecase, and the orchestrator can take
further actions based on result of DMS's detailed analysis.

Thanks,
Yuhei

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Aug 2019 13:07:39 +0000

> Sent: Tuesday, August 6, 2019 6:23 PM
> > > > > > Envoyé : mardi 6 août 2019 11:29 À : BOUCADAIR Mohamed
> > > > > > > > > This email originated from outside of the organization.
> > > > > > > > > Do not click
> > > > > > > > links or
> > > > > > > > > open attachments unless you recognize the sender and
> > > > > > > > > know the content is safe.
> > > > > > > > >
> > > > > > > > > Re-,
> > > > > > > > >
> > > > > > > > > Please see inline.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Med
> > > > > > > > >
> > > > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar
> > > > > > > > > > Reddy [mailto:[email-masked]]
> > > > > > > > > > filtering rules to block or rate-limit traffic to
> > > > > > > > > > routers (last but one line in the new paragraph).
> > > > > > > > >
> > > > > > > > > > IP addresses were spoofed cannot access the services
> > > > > > > > > > of the target server.
> > > > > > > > >
> > > > > > > > > [Med] This is a check at the DMS side. This check
> > > > > > > > > applies independently
> > > > > > > > of **
> > > > > > > > > where ** the filters are applied. This is not specific
> > > > > > > > > to this NEW
> > > > > > text.
> > > > > > > >
> > > > > > > > traffic, checks are required to ensure spoofed IP address
> > > > > > > > are not conveyed by
> > > > > > the
> > > > > > > DMS.
> > > > > > >
> > > > > > >   with additional hints such as its blocked traffic
> > > > > > > information to
> > > > the
> > > > > > The blocked traffic information will include attack traffic
> > > > > > from both spoofed and attacker IP addresses.
> > > > > >
> > > > >
> > > > > [Med] If you are saying that there is an issue if the DMS does
> > > > > not
> > > > check, you
> > > > > are right. But, again, this is not specific to the NEW text.
> > > > > This is a
> > > > general
> > > > No, DMS will anyway check and try not block legitimate traffic
> > > > from users whose IP addresses have been spoofed.
> > > >
> > >
> > > > > > > > the orchestrator delegates the mitigation to a separate
> > > > > > > > domain (recursive signaling), the attack information
> > > > > > > > provided by DMS can include spoofed IP addresses (so the
> > > > > > > > new mitigator in the separate domain learns the attack
> > > > > > > > traffic is coming from spoofed IP
> > > > addresses).
> > > > > > >
> > > > > > addresses to filter traffic would penalize legitimate users,
> > > > > > and the text is not clear me. I suggest adding a line for
> > > > > > clarity, DMS may supply both spoofed and attacker IP addresses
> > > > > > in the attack information to the orchestrator. The
> > > > > > orchestrator will only use the non-spoofed IP addresses to
> > > > > > enforce filtering rules on
> > routers.
> > > > >
> > > > > "its blocked traffic information", but if you prefer the text to
> > > > > be explicit,
> > > > it will
> > > > > need to be generic:
> > > > >
> > > > When DMS generates the attack traffic information it should
> > > > include both spoofed and attacker IP addresses (tagged with
> > > > whether the IP address is spoofed or not).
> > >
> > > > mitigator in the separate domain has knowledge that the attacker
> > > > is using spoofed IP addresses and the mitigator can optionally use
> > > > the attack information to determine the mitigation strategy.
> > >
> [Med] Because the use-case draft does not cover this: It only covers the case
> of an orchestrator talking to local routers.

My question is why shouldn't the use case draft cover this ?

> > > > based on the non-spoofed attacker IP address and not use the
> > > > spoofed victim IP addresses.
> > > >
> > >

No, sending attack information to the DOTS server is not covered in any of the WG documents.

> > the specification discussing offload scenario with propagating the
> > attack information and I recommend updating the text discussing the
> > above scenarios.
> 
> [Med] We don't have a similar text for the DMS case because mitigation is
> out of scope. I'm expecting to follow the some rationale for the offload.

If mitigation is out of scope, remove the following line:
Then the orchestrator can take further actions like requesting forwarding nodes such as routers to filter the traffic.

-Tiru

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 6 Aug 2019 16:07:53 +0300

> the WG consensus regarding the latest addition of a new use case to the draft.

I support advancing the draft as it is now.

--
Töma

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 13:13:29 +0000

Hi Yuhei,

I was not questioning the new offload text. My question to Tiru was about new security issues specific to the offload. 

From where I sit, I still don't see any specific issue induced by the offload. 

Cheers,
Med

> De : H Y [mailto:[email-masked]]
> Envoyé : mardi 6 août 2019 15:06
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; Valery Smyslov; [email-masked]; Xialiang
> (Frank, Network Standard & Patent Dept)
> based on
> > [Med] Agree. Whether the check is done at the orchestrator or by the
> DMS, is not a new concern. The DMS has to proceed with these checks,
> anyway. I fail to see what is NEW and SPECIFIC to the offload scenario.
> [Yuhei]

---

From: <[email-masked]>
Date: Tue, 6 Aug 2019 13:35:44 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : mardi 6 août 2019 15:08
...
> My question is why shouldn't the use case draft cover this ?

[Med] Isn't this captured with the following? 

   o  DDoS Mitigation System (DMS): A system that performs DDoS
      mitigation.  The DDoS Mitigation System may be composed by a
      cluster of hardware and/or software resources, but could also
      involve an orchestrator that may take decisions such as
      outsourcing partial or more of the mitigation to another DDoS
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      Mitigation System.

And 

   Another typical scenario for this use case is the relation between
   DDoS Mitigation Service Providers forming an overlay of DMS.  When a
   DDoS Mitigation Service Provider mitigating a DDoS attack reaches it
   resources capacities, it may choose to delegate the DDoS Mitigation to
   another DDoS Mitigation Service Provider. 

> > > DMS,
> > > > is not a new concern. The DMS has to proceed with these checks,
> anyway.
> > > I
> > [Med] This requirement has to be followed by the DMS, anyway. This is
> not a
> > new issue, Tiru.
> 

[Med] The text is about "additional hints". This is all what DOTS is about :-)

> Then the orchestrator can take further actions like requesting forwarding
> nodes such as routers to filter the traffic.

[Med] This sentence is similar to saying the "DMS starts mitigation" but with more contextualized information for a network orchestrator. The sentence uses "can", "like" which is fine for illustration purposes. As a reader, I prefer to leave it.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 7 Aug 2019 06:35:03 +0000

> Sent: Tuesday, August 6, 2019 7:06 PM
> > > [Med] Because the use-case draft does not cover this: It only covers
> > > the
> > case

I missed above text, Thanks.

> > > > > > filtering rules on routers, it should create the black-list
> > > > > > rules based on the non-spoofed attacker IP address and not use
> > > > > > the spoofed victim IP addresses.
> > > > > >
> > > > >
> > > > In this case the check has to be done by orchestrator when
> > > > enforcing black-list rules not to penalize the spoofed victim IP
> > > > addresses and should be discussed in the new use case.
> > >

Yes, but the NEW text is discussing conveying attack information for the first time and it needs more details.

> > > > attack information and I recommend updating the text discussing
> > > > the above scenarios.
> > >
> > > [Med] We don't have a similar text for the DMS case because
> > > mitigation
> > is
> > Then the orchestrator can take further actions like requesting
> > forwarding nodes such as routers to filter the traffic.
> 
> [Med] This sentence is similar to saying the "DMS starts mitigation" but with
> more contextualized information for a network orchestrator. The sentence
> uses "can", "like" which is fine for illustration purposes. As a reader, I prefer
> to leave it.

I suggest to add more details discussed in the thread. Anyways, will leave it to you and the authors to decide, and I am not objecting to progressing the draft 
without the proposed update.

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Thu, 8 Aug 2019 07:14:10 +0000

Hi Tiru, 

OK. I prepared a proposal at: https://github.com/dotswg/dots-use-cases/pull/11/files 

Cheers,
Med

> Envoyé : mercredi 7 août 2019 08:35
> I suggest to add more details discussed in the thread. Anyways, will leave
> it to you and the authors to decide, and I am not objecting to progressing
> the draft

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 8 Aug 2019 07:23:30 +0000

> Sent: Thursday, August 8, 2019 12:44 PM
> Cc: [email-masked]

Thanks, looks good.

Cheers,
-Tiru

> > > > > [Med] Because the use-case draft does not cover this: It only
> > > > > covers the
> > > > case
> > >    resources capacities, it may choose to delegate the DDoS
> > > Mitigation
> > to
> > > > > > > > filtering rules on routers, it should create the
> > > > > > > > black-list rules based on the non-spoofed attacker IP
> > > > > > > > address and not use the spoofed victim IP addresses.
> > > > > > > >
> > > > > > >
> > > > > > enforcing black-list rules not to penalize the spoofed victim
> > > > > > IP addresses and should be discussed in the new use case.
> > > > >
> > Yes, but the NEW text is discussing conveying attack information for
> > the first time and it needs more details.
> >
> > >
> > > > >
> > > > > > the specification discussing offload scenario with propagating
> > > > > > the attack information and I recommend updating the text
> > > > > > discussing the above scenarios.
> > > > >
> > > [Med] This sentence is similar to saying the "DMS starts mitigation"
> > > but
> > with
> > > more contextualized information for a network orchestrator. The
> > > sentence uses "can", "like" which is fine for illustration purposes.
> > > As a reader,
> > I prefer
> > > to leave it.
> >
> > I suggest to add more details discussed in the thread. Anyways, will
> > leave it to you and the authors to decide, and I am not objecting to
> > progressing the draft without the proposed update.
> >
> > Cheers,
> > -Tiru

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 15 Aug 2019 11:57:23 +0300

Hi,

there was some discussion around the new text in the draft, but 
nobody objected to the addition of this text.
So the chairs believe that there is a rough consensus in the WG
and the draft is ready for IESG evaluation.

Regards.
Frank & Valery.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 15 Aug 2019 12:05:58 +0300

Peace,

On Thu, Aug 8, 2019, 10:14 AM <[email-masked]> wrote:

> Hi Tiru,
>
> OK. I prepared a proposal at:
> https://github.com/dotswg/dots-use-cases/pull/11/files
>

I completely agree with the addition of this.

--
Töma

---

From: H Y <[email-masked]>
Date: Thu, 15 Aug 2019 21:25:04 +0900

Hi,

> OK. I prepared a proposal at: https://github.com/dotswg/dots-use-cases/pull/11/files
Thank you for the proposal. I agree with it too.

Thanks,
Yuhei