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

[Dan Wing <[e-mail]>]

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.  

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?  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", 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?), 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 ___"?

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.



-d




> On Nov 21, 2018, at 11:54 PM, [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]); [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]>
>> <[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]]
>>>> 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.
>>>> 
>>>> The IETF Secretariat
>>> 
>>> _______________________________________________
>>> Dots mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dots