Re: [Int-area] Adam Roach's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

Suresh Krishnan <suresh.krishnan@gmail.com> Thu, 23 January 2020 06:55 UTC

Return-Path: <suresh.krishnan@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1293B12010E; Wed, 22 Jan 2020 22:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 imlAzyrX5NGG; Wed, 22 Jan 2020 22:55:07 -0800 (PST)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809A412003F; Wed, 22 Jan 2020 22:55:07 -0800 (PST)
Received: by mail-pj1-x1034.google.com with SMTP id a6so757443pjh.2; Wed, 22 Jan 2020 22:55:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sO33d1DSu4KIKbKpRClhkl5x7VWx9FMqjhmqW+JEcNI=; b=emsNy2Lx2AMm8vMjTLtfXoGx5QSei2wNfY2oSOHahmqKmeZ7LX5vlI7x/aJ1w4N1vQ z6zra0fSJ89rm+WU9B5ZA2q1s68yUZQpS8FQlUiQScZvlk+8SBDgAk2yDaV9IFQH7HnG fPygNJR/uM9ZDGEVQdidBlHZz139ydOrwrT5P8ykMfmdGiqcqdLjPixjQ4ub8MAjWIGk De9sFGyrR2P/iP+rYylR48aLA0LoP/F9qAy2PTwfw8EOyKZuokp9bTujtbSslsLRD/67 eLCRaqUtcrjDeqXm3ZzFidEgvuRTotS81pxYVc1M2eQrozUBkVEOdsh8TQQ++HdQP8lR htyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sO33d1DSu4KIKbKpRClhkl5x7VWx9FMqjhmqW+JEcNI=; b=SjP1wUIx2mUjPhEV6qVo+U+I5FfcN25smna5iSaXZY+e/PEG14nOSxvFL5pFqB/agM mAy1RCq3mqe+c6fb9DBTxQ3Yq9L0mRQa638UoxXGYTKyvvfw7Ux8p/R2TsHi8VrHp06m JjZVsu8u4hPpPakiKLJ6cjJD/09TAfxGj+JowK9l+vDTOTqRvlp3ttujHg4eT6ieQfdS JvF/bFqZk+oh28QpFjyhUDtosVh0v35ZrPt3sRWdlE3KlMHkoKywmdHdV4zyxjrBYBFH ekaJE+puUWqpi3SJgHIosliDg4iia7On0tFDxt/62ejm0m3iYqsRS+51/GiYEEcX9kH5 pUAw==
X-Gm-Message-State: APjAAAUm+KDl/3O/rEKdh2heNpXrBkVn+jRQCwSQ1RIug17CR45kQK5B Zs5/2I+1ZnCDX784ZSZ/mbY=
X-Google-Smtp-Source: APXvYqx/pPynaR/VAfiBHJlRA+73Hd9vHCZZzlcGM3hA+obkJUyde1mddjDcw4mRYwtHGZ9N592fsQ==
X-Received: by 2002:a17:90a:31cc:: with SMTP id j12mr2778267pjf.103.1579762506985; Wed, 22 Jan 2020 22:55:06 -0800 (PST)
Received: from [172.20.7.143] ([12.199.201.12]) by smtp.gmail.com with ESMTPSA id p185sm1181499pfg.61.2020.01.22.22.55.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 22:55:06 -0800 (PST)
From: Suresh Krishnan <suresh.krishnan@gmail.com>
Message-Id: <B9C88E7D-51BB-415A-A174-B149CD42931A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6BA94E42-8012-438A-9AA5-AEE57CD65E5D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Thu, 23 Jan 2020 01:55:05 -0500
In-Reply-To: <B873983A-1327-4388-8B9E-BEC8D2008450@apple.com>
Cc: Adam Roach <adam@nostrum.com>, ek@loon.com, draft-ietf-intarea-provisioning-domains@ietf.org, int-area@ietf.org, The IESG <iesg@ietf.org>, intarea-chairs@ietf.org
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
References: <157967080772.28909.16443816599872682093.idtracker@ietfa.amsl.com> <6AFB6A09-59BF-411D-816F-914BAAF86A9B@apple.com> <a1daf959-3331-e86d-2734-1f63a98d7625@nostrum.com> <BF4953C0-2502-4E08-B8B3-B55D04475416@apple.com> <3c3fb029-be06-02a2-1ac2-d23a3183d09a@nostrum.com> <7BBB92DD-7C0D-4A30-AE5D-3DB6A8424B9A@apple.com> <4b2b529f-9e67-b6d0-1a9c-b6ad5cd96f01@nostrum.com> <B873983A-1327-4388-8B9E-BEC8D2008450@apple.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/7RGW6FH0f80G6NRkgi6T47W3qNI>
Subject: Re: [Int-area] Adam Roach's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 06:55:09 -0000


> On Jan 22, 2020, at 7:18 PM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Jan 22, 2020, at 4:08 PM, Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>> wrote:
>> 
>> Thanks again for the quick turn-around on this.
>> 
>> Using your proposed 2**(Delay + 10) seems to strike an okay balance, if I'm understanding the situation correctly. Double-check my thinking here: the scope of RA reach from an attacker will be available only on a single local link, which deployments typically limit to on the order of 500 clients or so. If all 500 are triggered at the same time and smooth out their requests over a one-second window, we're looking at a 500 TPS load on a web server. That's about 25% the capacity of a relatively low-end web server (e.g., Apache running on an Atom 1.66), which seems small enough to avoid major issues.
> 
> Yes, that sounds right to me. That limits the single burst size in response to a given RA being sent. Each of these hosts wouldn't request again for that PvD ID, even if RAs keep coming telling the host to update, for another ten seconds after that. And, the limit for the number of different hostnames (for a case in which a wildcard host exists, which presumably also has a higher capacity) is 5 different names in the ten second period, so that limits at 2500 TPS across all fetches to any server from a given network.
>> 
>> So, unless one of my assumptions above is wrong, I think your proposal below is a good solution to the issue. I'll clear my DISCUSS when a new version of the draft comes out (I would propose that you wait for instructions from your AD about when to do so).
> 
> Thanks! Yes, I'll wait for the go-ahead from Suresh. I appreciate your helping to work through these important details!

Yes. I had asked Tommy to hold off on submitting a new version until after the telechat so that there is no confusion with different ADs reviewing different versions of the draft. Will work with Tommy to ensure that the agreed changes are reflected in the new submitted version.

Regards
Suresh