Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Thu, 20 February 2014 15:41 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE961A01C8 for <v6ops@ietfa.amsl.com>; Thu, 20 Feb 2014 07:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.049
X-Spam-Level:
X-Spam-Status: No, score=-17.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ai19HD1xuCIA for <v6ops@ietfa.amsl.com>; Thu, 20 Feb 2014 07:41:40 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C70E61A0170 for <v6ops@ietf.org>; Thu, 20 Feb 2014 07:41:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2256; q=dns/txt; s=iport; t=1392910897; x=1394120497; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DBuohPPhKVsGd+BUYR+ARHqqxYPwQ77IHuwLgtBA4Yo=; b=CLvjbUPDJexaqkejDIlIEwJgcXgNuI2QL3cQjaJ7DyHrvBauIqOVf7Xh MyJAgMduKKS+pJ70iamQyoSNn1pvrnLlg+OHeqwG/iTALOIiEI7IQRUeb UkbpWWW0Sn75IeQ2VKX1pAEO40CGjb0zRFQ796jD02+fVJXYVWPzGfYB1 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAPQgBlOtJXG+/2dsb2JhbABZgwY4V8AMgRAWdIIlAQEBBAEBAWsLEAIBCBguJwslAgQBDQWIBQ3OKBMEjgxYB4Q4BIkQjyCSJIMtgWgjHw
X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305397458"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 20 Feb 2014 15:41:37 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1KFfb7k020273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 15:41:37 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 09:41:36 -0600
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Jan-Frode Myklebust <janfrode@tanso.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt
Thread-Index: AQHPKWgFc33rJRWVT02NFletWRLbG5q06NoAgAD96gCAAR81gIABVkQAgAA9hYCAAAN0gIAAC5wAgAEH0ICABRZeAA==
Date: Thu, 20 Feb 2014 15:41:35 +0000
Message-ID: <CF2BDFBA.DAF1%evyncke@cisco.com>
References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <m21tz6javn.wl%randy@psg.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <BD473E46-E382-44E6-B474-A56D074318FA@delong.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin>
In-Reply-To: <20140217110013.GA31822@mushkin>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.55.185.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <425CD688BC1C424FAA8788696B0839E6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_aB7rAPzhJjrp-iYj1ZQW3gK2CY
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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 Feb 2014 15:41:43 -0000

To come back to the draft itself...

Section 2.2 'globally unique', should stress that the randomization
process MUST be followed to the letter. Also, as discussed in the list,
the 40 bits of entropy are for a single /48, if hundreds of /48 need to be
generated, this will reduce the entropy to 30 bits or so... (which is
still 8 billions though).

Section 4.2 'limited scope', as a security person, I would really love to
read it clearly articulated that ULA does not provide isolation per se...
Bi-directional ACL are required + route map to avoid polluting your BGP
neighbors. Jan-Frode, I am sure that you know that strict policy routing
(without anti-spoofing or ACL) will not prevent packets from you DC to
leak to the Internet (to the NSA or any other 'interested' party ;-))

-éric

On 17/02/14 12:00, "Jan-Frode Myklebust" <janfrode@tanso.net> wrote:

>On Mon, Feb 17, 2014 at 08:16:00AM +1300, Brian E Carpenter wrote:
>> >>> Le 15/02/2014 19:16, Owen DeLong a écrit :
>> >>>> Indeed, the situations where ULA usage is detrimental vastly
>> >>>> outnumbers those where it is actually beneficial.
>> 
>> That's an opinion, but it isn't an argument for abolishing
>> ULAs. It's actually an argument for improving this draft so
>> that it describes the cases in which ULAs are beneficial.
>
>> Could we have a detailed conversation about whether those cases
>> are correctly described in the draft?
>
>Yes please.
>
>My use case is that we have a set of datacenter internal services/servers
>that should *never* be routed out. When not using ULA we've had a couple
>of incidents where the routes did leak out and servers that shouldn't
>have been available on the Internet was. So we've decided to use ULA for
>the same set of servers as we previously used rfc1918-adresses for. No
>NAT involved. No servers should reach Internet directly. Yes we could
>achieve the same by putting proper ACLs in place on the borders, but since
>we've failed to do that in the past, the belt and suspenders approach is
>attractive.
>
>Is this a "valid" ULA usage?
>
>
>  -jf
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops