[v6ops] Comments on ULA draft

Lorenzo Colitti <lorenzo@google.com> Thu, 20 July 2017 12:21 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412A131C06 for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 05:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 s5V5KhEyu6Wm for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 05:21:42 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 58F4912EC30 for <v6ops@ietf.org>; Thu, 20 Jul 2017 05:21:42 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id v127so14989311itd.0 for <v6ops@ietf.org>; Thu, 20 Jul 2017 05:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WtDDF2tISolSHBc3DVsRMs3T3eR7FUCiTIl6EQHhv8E=; b=pjsPxDr1McoZ5cM41ufjgOpklQSKCrYiL9kTCa0zfiLDtSA44vBBlKXK9Pr7QldyZy yEmHjMHXSzJkr7gGBTWw3q2n89su1yQE5D/sTPERco8ZItKF9zbX5IpDC/hnXKjd6921 N/5zAJ/GVW+A8U6Gi9HxqBELq8QTKQtLabLloo3XGU7VWBFc85oKAKx6Zi2KClTYhHFE x2lYSz4DsvvkHdLs5X9paA/5GcLz3WSx3LO1+RVXFqg9FvDndzfwF2BDU5qGwxZFuVF2 38vM27xsjWi119xHKJowYbeY5zmWaf+G+sTSuUhm2ssB0ZBmQxylzJEEZYkmqQdj4LVn 2fVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=WtDDF2tISolSHBc3DVsRMs3T3eR7FUCiTIl6EQHhv8E=; b=LluukWqkzUzVw7JyS368HQe5FNFzcdKYy0W2+oIlleuYw/50UFOCqwqVWKZRBx1lck oj0oniD0c5mJt9YOAYlUPDyNLzJplxxAnpcIGf4t4NlXU/aI8kEBFnL5SS6KZOqTS+HO xeE4zs0czEZ0inBCZPhFKFsPBYIYaOAS0vnfKJSRJatsr5mvBPSDqUXj2BUlBxP5Lpug GEhUf2MrCrClALrktbhkwu8Xq2ZPSQhod+noZjrBl1LwVbuzxSqUnxwJGiGwoSO3QNUP fgX0Ykb6kgUPePszoTRGy4ATYwmuBN7sQIxkBoI5bKjHGWiTdu18/tI5j8woxF8BTAtb 8M6A==
X-Gm-Message-State: AIVw110RfeTHtip+xOZkX3rbg1Bb5RnsQejNzThTIvXzUb54Wg+emEHL 3LtL9fF6NggheYFrRx5qX5Ac3ZgRNKxcfJk=
X-Received: by 10.36.4.139 with SMTP id 133mr3217168itb.142.1500553301148; Thu, 20 Jul 2017 05:21:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 05:21:20 -0700 (PDT)
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 20 Jul 2017 14:21:20 +0200
Message-ID: <CAKD1Yr1p5Lkx=N5O+MHaj1MMKmbUi+bEf7YeiVrqbY3redp3pg@mail.gmail.com>
To: "v6ops@ietf.org WG" <v6ops@ietf.org>
Cc: draft-ietf-v6ops-ula-usage-considerations@ietf.org
Content-Type: multipart/alternative; boundary="001a113fe1e27c05bc0554beca60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_wdTzjEgeVIuiDoflMVN1SL1Xx8>
Subject: [v6ops] Comments on ULA draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 12:21:49 -0000

Repeating the comments at the mike:

   1. As clearly shown in the presentations slides, and as said by others,
   there will continue to be is substantial opposition to any document unless
   it says that ULA+NPTv6 deployments are NOT RECOMMENDED. The current text in
   section 4.3 is very far from making such a statement.
   2. The document needs to be clear that because ULAs MUST be generated
   randomly (per RFC 4193), they are not aggregatable. Thus, developing ULA
   firewall policies is very complex because there is no way to ensure that
   /48s with similar security policies have adjacent address space. Even if
   ULA is initially deployed in a network that has only two zones ("public"
   and "private") network growth or mergers with other networks will cause
   firewall policies to become complex and have lots of holes.
   3. The document should say that even though ULAs are typically not
   announced externally, any network that is adjacent to the ULA network can
   send and receive packets from ULA addresses unless there is a firewall rule
   that blocks such packets. For well-connected networks that have lots of
   peers, that can be a large attack surface.
   4. Due to #2 and #3, it may well be simpler to use global space and just
   add a firewall.


Regards,
Lorenzo