Subject: [Dots] Comments on draft-nishizuka-dots-signal-control-filtering-02

From: "Panwei (William)" <[email-masked]>
Date: Fri, 25 Jan 2019 07:57:59 +0000

Hi Med,

I have read the latest version and I have 2 comments on it.

It is RECOMMENDED for a DOTS client to subscribe to asynchronous
notifications of the attack mitigation, as detailed in
Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the
polling mechanism in Section 4.4.2.2 of
[I-D.ietf-dots-signal-channel] has to be followed by the DOTS client.

Here you have listed two ways for a DOTS client to follow. Since you used “has to” to indicate that DOTS client must follow the polling mechanism when it doesn’t follow the RECOMMENDED way, would it be better for changing “has to” to “MUST”?

A DOTS client MUST NOT use the filtering control over DOTS signal
channel if no attack (mitigation) is active. By default, ACL-related
operations are achieved using the DOTS data channel
[I-D.ietf-dots-data-channel] when no attack is ongoing.

Though we have given the principle for the DOTS client to follow, but we don’t give a corresponding principle for the DOTS server to check. If the DOTS client is misbehaved and the DOTS server doesn’t check, then new security issues may arise.

Do we want to add some rules and methods for the DOTS server to check, or describe this potential threat in the Security Considerations Chapter?

Best Regards

Wei Pan

---

From: <[email-masked]>
Date: Fri, 25 Jan 2019 09:08:35 +0000

Hi Pan,

(1) What is recommended is to enable asynchronous notif (hence the use of the normative language). I’m hesitating to use the normative language for the second sentence.

(2) No text was included about the DOTS server because we do already have the following in the signal channel:

   If the request is missing a mandatory attribute, does not include
   'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
   parameters, or contains invalid or unknown parameters, the DOTS
                           ^^^^^^^
   server MUST reply with 4.00 (Bad Request).

Can you please elaborate on the security issues you have in mind? Thank you.

Cheers,
Med

De : Panwei (William) [mailto:[email-masked]]
Envoyé : vendredi 25 janvier 2019 08:58
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]
Objet : Comments on draft-nishizuka-dots-signal-control-filtering-02

Hi Med,

Best Regards

Wei Pan

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 25 Jan 2019 10:19:38 +0000

Hi Med,

Please see inline.

Best Regards
Wei Pan

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 25, 2019 5:09 PM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on draft-nishizuka-dots-signal-control-filtering-02

Hi Pan,

(1)What is recommended is to enable asynchronous notif (hence the use of the normative language). I’m hesitating to use the normative language for the second sentence.

[Wei] Because there are only two ways that you have listed for the DOTS client to choose, if the DOTS client doesn’t choose the recommended way, then it must choose the other way.
Unless there is a third way, otherwise the meaning here is normative even though you don’t use a normative language.
Is there a third way? If not, the normative language is appropriate, IMO.

(2)No text was included about the DOTS server because we do already have the following in the signal channel:

[Wei] I think adding a reference to this can make the control-filtering draft more readable.

[Wei] Please forget this, I didn’t think clearly at the beginning.
At first, I thought the misbehaved DOTS client might abuse the signal channel to send acl-list continuously, and this might cause the signal channel jammed. Or the client might enable and disable the acl-list alternately and continuously, and this might cause the server busy.
But these are all not new issues, these issues also exist before, only there is no acl-list included in the request messages.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

Hi Med,

Best Regards

Wei Pan

---

From: <[email-masked]>
Date: Fri, 25 Jan 2019 12:33:36 +0000

Re-,

Please see inline.

Cheers,
Med

De : Panwei (William) [mailto:[email-masked]]
Envoyé : vendredi 25 janvier 2019 11:20
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]
Objet : RE: Comments on draft-nishizuka-dots-signal-control-filtering-02

Hi Med,

Please see inline.

Best Regards
Wei Pan

Hi Pan,

[Wei] Because there are only two ways that you have listed for the DOTS client to choose, if the DOTS client doesn’t choose the recommended way, then it must choose the other way.
Unless there is a third way, otherwise the meaning here is normative even though you don’t use a normative language.
Is there a third way? If not, the normative language is appropriate, IMO.
[Med] I don’t know if there will be any equivalent mechanism in the future, but if that alternate mechanism exist, it is completely fine for the client to use it as a backup.

[Med] OK.

[Med] Indeed. Furthermore, a valid request has to include a mid which is maintained by the server. Otherwise, the request will be rejected by the server.

Cheers,
Med

Hi Med,

Best Regards

Wei Pan