Re: [Dots] New Version Notification for draft-reddy-dots-home-network-02.txt

[<[e-mail]>]

Hi Dan,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : Dan Wing [mailto:[e-mail]]
Envoyé : jeudi 13 décembre 2018 18:28
À : BOUCADAIR Mohamed TGI/OLN
Cc : Roman Danyliw; Xialiang (Frank, Network Integration Technology Research Dept); Panwei (William) ([e-mail]); [e-mail]
Objet : Re: [Dots] New Version Notification for draft-reddy-dots-home-network-02.txt

Modified text in 1.2 now says:

   Unlike classic DOTS deployments
   [I-D.ietf-dots-use-cases], such DOTS server maintains a single DOTS
   signal channel session with an upstream DOTS client, if the CPE is
   single-homed.

The phrase "if the CPE is single-homed" caught me off-guard, because you're not saying how multi-homed is handled or providing guidance to implementations for how to learn how to handle multi-homing.  Perhaps change from "if CPE is single-homed" to "for each upstream provisioning domain"?  Maybe you want to cite the multi-homing document informationally, but could be useful.

[Med] OK. I updated the text to "for each DOTS-capable upstream provisioning domain" because some upstream network may not offer a DOTS client. I also cited the multi-homing I-D.

The new text in 3.2.1 starts with "

  "When a Carrier Grade NAT (CGN) is located between the DOTS client and DOTS server,"

what is the mechanism for the DOTS client and server to determine there is a Carrier Grade NAT between them, such that the rest of the requirements in the paragraph have to be followed; that is, is there a DOTS mechanism like ICE messages to determine address rewriting occurred?

[Med] The assumptions are the following:

·         The DOTS client is operated by the same entity as the CGN

·         Communicating the external IP address/port (IP2) when a translator is on-path won’t be helpful for the DOTS server because the server may not even aware of the existence of the translator

·         It is safe then for the DOTS client to interact with the CGN to determine the internal IP address/port (IP1) which is mapped to an external IP address/port. We are citing opsawg-nat as one way to achieve that, but other tools may be used as well.

DOTS Server----CGN---DOTS Client
    IP1        IP2

ICE (and the like) is not cited because it does not solve that problem from the perspective of the DOTS client.

We could assume that the DOTS server uses some means to learn the mapping once it receives a request from the DOTS client, but this is suboptimal (and unreliable).


 Do the requirements in that paragraph apply only to CGN, as it reads -- it seems the requirements are the same as the paragraph slightly below which mentions "NAT on CPE"
[Med] The CPE text solves a distinct problem that the CGN one: the server validates the request, but needs to find which internal IP address/port (IP1) correspond to the IP address/port communicated by the DOTS client (IP2).


Hi---CPE----CGN---DOTS Client
IP1   IP2   IP3

H----CPE----------DOTS client
IP1  IP2

, but the phrasing is different so I can't tell if implementation is supposed to be exactly same.  How does a CGN get differentiated from a non-"Carrier Grade" NAT between the elements, from things as simple as an accidentally-installed NAT to things as complex as a laptop tethered to a NAT44 and 464xlat cellular phone and NAT64 in the carrier, where we might imagine DOTS in the laptop or the cellphone; I think the ISP-operated NAT64 qualifies as CGN (does it?)

[Med] NAT64 is considered as a CGN.

, but I need half hour of sketching to understand the situation here.  More succinctly:  can the requirements for NAT be simplified and explained why the requirements are necessary for interoperation, rather than saying "if CGN, then do ___", and "if NAT integrated into CPE do ___"?

[Med] That is fair. We will update that text to make it clearer.

In Privacy Considerations, new text says "Concretely, the protocol does not leak any new information that can be used to ease surveillance", but the new text in 3.2.1 says the internal IP address and port number (of the victim) are communicated to the DOTS server.  This is new information disclosed by DOTS.

[Med] Yes, but:


·         The internal IP address is already known to the CPE/DOTS server.

·         The internal IP address can already be used to set the target of an attack in “classic” DOTS.

Is there a particular issues that you think has to be raised?

[cid:image001.jpg@01D49381.661678C0]

[Med] Thanks :)
-d





On Nov 21, 2018, at 11:54 PM, [e-mail]<mailto:[e-mail]> wrote:

Hi Dan,

Enjoy your stay in Morocco!

Looking forward to receiving your review.

Cheers,
Med


-----Message d'origine-----
De : Dan Wing [mailto:[e-mail]]
Envoyé : jeudi 22 novembre 2018 08:20
À : BOUCADAIR Mohamed TGI/OLN
Cc : Roman Danyliw; Xialiang (Frank, Network Integration Technology Research
Dept); Panwei (William) ([e-mail]<mailto:[e-mail]>); [e-mail]<mailto:[e-mail]>
Objet : Re: [Dots] TR: New Version Notification for draft-reddy-dots-home-
network-02.txt

Currently I am in Morocco. Still useful to review next week?


-d


On Nov 13, 2018, at 3:37 PM, <[e-mail]<mailto:[e-mail]>>
<[e-mail]<mailto:[e-mail]>> wrote:


Hi Roman, Franck, Wei,

FYI, we released an updated version of the draft which integrates the
comments you raised. The main changes are as follows:


* Add a new privacy considerations section as suggested by Roman.
* Add a discussion on issues/fixes when an address sharing function is
present between the DOTS client and server (Wei)

* Add some text to clarify that the DOTS server on the CPE is simple
compared to the one on the provider side. Only a single DOTS session will be
maintained (Franck).

* Further highlight that the solution is suitable for blocking attacks near
the sources (I failed to get the name of the gentleman who raised this issue
in the meeting).

* Add some text to clarify that DOTS servers do not blindly accept requests
and that the solution does not aim to track or censor users (the comment was
made by same gentleman as above).


Please let us know if the new text addresses your concern.

As usual, comments, suggestions, and questions are more than welcome.

Cheers,
Med


-----Message d'origine-----
De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Envoyé : mardi 13 novembre 2018 15:28
À : Tirumaleswar Reddy; Joshi Harsha; Jon Shallow; Reddy K; BOUCADAIR
Mohamed

TGI/OLN
Objet : New Version Notification for draft-reddy-dots-home-network-02.txt


A new version of I-D, draft-reddy-dots-home-network-02.txt
has been successfully submitted by Mohamed Boucadair and posted to the
IETF repository.

Name:        draft-reddy-dots-home-network
Revision:    02
Title:        Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Call Home
Document date:    2018-11-12
Group:        Individual Submission
Pages:        17
URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-
home-

network-02.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-home-
network/
Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-home-network-
02

Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-dots-
home-

network
Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-home-
network-02

Abstract:
 This document presents DOTS signal channel Call Home service, which
 enables a DOTS server to initiate a secure connection to a DOTS
 client, and to receive the attack traffic information from the DOTS
 client.  The DOTS server in turn uses the attack traffic information
 to identify the compromised devices launching the outgoing DDOS
 attack and takes appropriate mitigation action.




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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Dots mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dots