Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31
Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 11 April 2019 06:06 UTC
Return-Path: <nishida@sfc.wide.ad.jp>
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 8E372120173; Wed, 10 Apr 2019 23:06:27 -0700 (PDT)
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 vcP48uu22urU; Wed, 10 Apr 2019 23:06:24 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EA0120074; Wed, 10 Apr 2019 23:06:23 -0700 (PDT)
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E4A5E29C009; Thu, 11 Apr 2019 15:06:20 +0900 (JST)
Received: by mail-wr1-f53.google.com with SMTP id s15so5551581wra.12; Wed, 10 Apr 2019 23:06:20 -0700 (PDT)
X-Gm-Message-State: APjAAAWHp6IPGHKKqLagXkKp48tmfOzdAeF76blV3JDbpJByvAI1moKi V3wuzrZw6Z61wad8J8w24ehMteC21dEE3qS/Xis=
X-Google-Smtp-Source: APXvYqyoMbAhaRCX59Jol5cqrnbsxwTG3N0poF0yvO0Kfo6Lh3TfwRZMhewrkj2UjxDznBzUub1RKQKiYqplDVYdSyE=
X-Received: by 2002:a5d:698b:: with SMTP id g11mr30664226wru.65.1554962778517; Wed, 10 Apr 2019 23:06:18 -0700 (PDT)
MIME-Version: 1.0
References: <155402239346.12345.7871170827596594079@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA5053A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249yf92bfdZCyfcQaHMt41SKO6CAQXOYEW2H++ZYQoXqKvpQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA51A15@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249yeRK7RJ59jcmpXkwFX5_RniwGoBCcno3tNsCcFCJiRhsA@mail.gmail.com> <BYAPR16MB27904373EA2F32A9805B239AEA510@BYAPR16MB2790.namprd16.prod.outlook.com> <CAO249yfhgvv3L9GxBQfYs-boeBecG+GhQSx90igDAuhA866WhA@mail.gmail.com> <BYAPR16MB2790E24D2D28A0C2AA981C0CEA2C0@BYAPR16MB2790.namprd16.prod.outlook.com> <CAO249ye9hD8eGRjsujsFtY=UXy29BYzHn-HeaOqgrPLNwU8dkA@mail.gmail.com> <BYAPR16MB279047FCA67C53A25FCE048EEA2D0@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB279047FCA67C53A25FCE048EEA2D0@BYAPR16MB2790.namprd16.prod.outlook.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Wed, 10 Apr 2019 23:06:07 -0700
X-Gmail-Original-Message-ID: <CAO249ycNT3z3n419Svor01HXPPmHY1sshuMb3SjWpczqSFVpqw@mail.gmail.com>
Message-ID: <CAO249ycNT3z3n419Svor01HXPPmHY1sshuMb3SjWpczqSFVpqw@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dots-signal-channel.all@ietf.org" <draft-ietf-dots-signal-channel.all@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Yoshifumi Nishida <nishida@wide.ad.jp>
Content-Type: multipart/alternative; boundary="0000000000000d780f05863afcea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/veybqJyq4Wj9raNrs2aM9wwlAgQ>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 06:06:28 -0000
Hi Tiru, On Tue, Apr 9, 2019 at 1:26 AM Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > Please see inline [TR3] > > > > *From:* Dots <dots-bounces@ietf.org> *On Behalf Of * Yoshifumi Nishida > *Sent:* Tuesday, April 9, 2019 12:26 PM > *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> > *Cc:* ietf@ietf.org; Yoshifumi Nishida <nishida@sfc.wide.ad.jp>; > draft-ietf-dots-signal-channel.all@ietf.org; dots@ietf.org; > tsv-art@ietf.org; mohamed.boucadair@orange.com; Yoshifumi Nishida < > nishida@wide.ad.jp> > *Subject:* Re: [Dots] Tsvart last call review of > draft-ietf-dots-signal-channel-31 > > > > *CAUTION*: External email. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > ------------------------------ > > Hi Tiru, > > > > I put my comments in lines. > > > > On Mon, Apr 8, 2019 at 1:40 AM Konda, Tirumaleswar Reddy < > TirumaleswarReddy_Konda@mcafee.com> wrote: > > Hi Yoshi, > > > > Please see inline [TR2] > > > > *From:* Yoshifumi Nishida <nishida@sfc.wide.ad.jp> > *Sent:* Monday, April 8, 2019 12:24 PM > *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> > *Cc:* Yoshifumi Nishida <nishida@sfc.wide.ad.jp>; > mohamed.boucadair@orange.com <mohamed..boucadair@orange.com>; > ietf@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; dots@ietf.org; > tsv-art@ietf.org <tsv-art@ietf..org>; Yoshifumi Nishida < > nishida@wide.ad.jp> > *Subject:* Re: [Dots] Tsvart last call review of > draft-ietf-dots-signal-channel-31 > > > > *CAUTION*: External email. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > ------------------------------ > > Hi Tiru, > > > > On Thu, Apr 4, 2019 at 10:46 PM Konda, Tirumaleswar Reddy < > TirumaleswarReddy_Konda@mcafee.com> wrote: > > Hmm. let's say the results of the happy eyeballs was TCP over IPv4 (just > like the figure 4) and the client cache the info. > > After certain period of time, the client will do happy eyeball again > because other better connections might be available . But, in this case, > how the cached info will be used? > > > > [TR] The cache expires after a specific time period. If the cache has not > expired, the client uses the information from the cache. If cache has > expired, the client performs happy eyeball again. > > > > It seems that an implementation that doesn't cache the info at all and > does happy eyeballs at every 10 hours won't be allowed in this draft. > > > > [TR] No, but if the subsequent attempt is within few seconds after the > first attempt of happy eyeball, it would trash the network. The endpoint > may have to re-establish the (D)TLS session within few seconds for several > reasons (e.g. TLS session got terminated, DOTS server rebooted NAT rebooted > etc.). > > > > Thanks for the explanation. The logic makes sense to me. > > I think it would be good to articulate this a bit more in the draft. > > For example, the figure 4 example explains the probing period, but doesn't > mention about the cache period. > > > > [TR2] > > Sure, we can update the text as follows: > > > > Note that the DOTS client after successfully establishing a connection > MUST cache information regarding the outcome of each > > connection attempt and the cached information should be flushed when its > age exceeds a system-defined maximum on the order of few minutes (e.g. 2 > minutes). > > If the DOTS client has to re-establish the connection with the DOTS server > within few seconds after the Happy Eyeballs mechanism is complete, > > caching avoids trashing the network in the presence of DDoS attack > traffic. > > > > Thanks for the updates. But, one thing.. The text suggests cache period > would be the order of few minutes. > > But, this value seems to be much smaller compared to "probing SHOULD NOT > be done more than every 24 hours". > > > > [TR3] The probing is for a scenario where the client is using TLS (over > TCP) for the signal channel and probes to check if DTLS (over UDP) becomes > available. If the probing finds DTLS over UDP is available, the client > disconnects the TLS over TCP and re-connects to the server using DTLS over > UDP transport. > Thanks for explanation. OK. so, probing and cache is irrelevant. I have thought about if this is confusing or not for a bit. But, I think it's ok after I re-read the text. I don't have any more comments. Thanks, -- Yoshi
- [Dots] Tsvart last call review of draft-ietf-dots… Yoshifumi Nishida via Datatracker
- Re: [Dots] Tsvart last call review of draft-ietf-… mohamed.boucadair
- Re: [Dots] Tsvart last call review of draft-ietf-… Yoshifumi Nishida
- Re: [Dots] Tsvart last call review of draft-ietf-… mohamed.boucadair
- Re: [Dots] Tsvart last call review of draft-ietf-… Yoshifumi Nishida
- Re: [Dots] Tsvart last call review of draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Tsvart last call review of draft-ietf-… Yoshifumi Nishida
- Re: [Dots] Tsvart last call review of draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Tsvart last call review of draft-ietf-… Yoshifumi Nishida
- Re: [Dots] Tsvart last call review of draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Tsvart last call review of draft-ietf-… Yoshifumi Nishida