IETF Logo Mail Archive

Re: [mif] next step for MIF PVD configuration

Margaret Cullen <mrcullen42@gmail.com> Sun, 13 March 2016 00:10 UTC

Return-Path: <mrcullen42@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC97412D677 for <mif@ietfa.amsl.com>; Sat, 12 Mar 2016 16:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ouvuRWidu8sM for <mif@ietfa.amsl.com>; Sat, 12 Mar 2016 16:10:03 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 9C11412D59C for <mif@ietf.org>; Sat, 12 Mar 2016 16:10:02 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id d65so130371050ywb.0 for <mif@ietf.org>; Sat, 12 Mar 2016 16:10:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=G3BaD8BecF51+8Sa4ywjkQc7QU2S1Lh9UuMGXpsULm0=; b=edgiWTnNQQikCVDDjyP5br3eqrIwus3bBciWa0CFC7kOPjMV6Ct/CLgEZGp+/x3Mtt QQ8l/jf2nyiQt2vLmekXbFnFNktTbgO0wEAW9CVOnRsDRtFCV0OMlh1X0eXeElIRVCtJ rkbM3BCOa8KHyYbaSezOwvO4HqtgOWZK5FldKCZkwSAr7IqJ2ckXIkdixC9OfFTy2FKO BLFEOdAD/BQ3D6ZKWWnsU/eFagJYMnFKKbN2CqiT9QEckoOdv3POLmvBbdmo8MCyElmd xVSqg+gs7zXF41gNtDXQkseLNkhacuupupy+NV0r493iTCxHoLcT7qoWzwUGLnF3eeqe CHkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=G3BaD8BecF51+8Sa4ywjkQc7QU2S1Lh9UuMGXpsULm0=; b=QK6YVnxn9IVm2/STI9AWdEowYepzyJoMTslejuXBPg74A8fB+e5BjEXJ/7wl7uJA0P 0qMaWdlkHP+VVd0pktnNLG0YwoYpg3Pj4/KJEv4q72U8YUldhU0AZTQwd4XG5BF6vqZE 8QyRwz9itmPwB8uvxeNdEssDvtvp+DvfkKteR5v4oNgxKYCYMePUWHpwpEqNZxKsMIDh P/7uQNlTYPzZsxADX7m57S/7ktdiIbTI8jPl/tavuDpRvXXlnBLN4HLIt1Zw3fDJ8ysD /Q/LIk47mV5ia2oVCNoCLgJOhhocNfxPf26PslDSPXrqSZYxfQiIdKDzFTNXOfkQpv7B eDUg==
X-Gm-Message-State: AD7BkJIjakrckCWodvGTuSwXIMlJ580lG5IoANHF4VEhyoPuAJMjpzF67OGUfbl1/6qWvw==
X-Received: by 10.37.2.211 with SMTP id 202mr9192159ybc.15.1457827801695; Sat, 12 Mar 2016 16:10:01 -0800 (PST)
Received: from new-host.home (pool-72-74-19-153.bstnma.fios.verizon.net. [72.74.19.153]) by smtp.gmail.com with ESMTPSA id e4sm9882657ywb.0.2016.03.12.16.10.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 16:10:01 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_6DF0E16E-8E20-49E5-9BFF-B4F62348E5C7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <alpine.DEB.2.02.1603041334290.31096@uplift.swm.pp.se>
Date: Sat, 12 Mar 2016 19:10:00 -0500
Message-Id: <B1328946-34AD-4222-813E-3B7A67B5B6CA@gmail.com>
References: <COL125-W396ADD4D31445DAE7867D3B1BA0@phx.gbl> <56D44703.7050700@fer.hr> <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> <56D82434.5020803@fer.hr> <alpine.DEB.2.02.1603041334290.31096@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/_D42dqzS424taNRp-4oTU6PCWhQ>
Cc: mif@ietf.org
Subject: Re: [mif] next step for MIF PVD configuration
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Mar 2016 00:10:04 -0000

Hi Mikael,

I agree with some of the issues you have raised about the current draft for DNS lookups of PVD information.  I think that if we go with a DNS-based approach, we will need to do some work on the DNS mechanism to fix these sorts of issues.

Do you have time to write a draft for the mechanism you have suggested, so that we can discuss it in the group?

Margaret

On Mar 4, 2016, at 7:48 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Thu, 3 Mar 2016, Stjepan Groš wrote:
> 
>> Finally, obviously this solution assumes a single DNS server from one ISP will provide all the data about PvDs. If you have two or more ISPs and expect them to be collaborative is nice thing to hope for, but in case they don't user is stuck. And even if they collaborate, that neither scales nor is responsive.
> 
> I re-read draft-stenberg-mif-mpvd-dns-00 . It's not obvious to me if the PvD information is globally available for anyone to ask (or not), or if there is a requirement for some kind of split horizon DNS view where you need to ask from an address within the PvD to actually get an answer back regarding the PvD.
> 
> I have doubts about the DNS method, and I would prefer to have some kind of other mechanism to distribute the PvD information.
> 
> What about having one more level of indirection (yeah, yeah, I know, RFC 1915 6a), and instead find the configuration resource via some kind of SRV record either available via DNSSD or via PTR .arpa lookup, or via DHCP option? Then the information could be fetched using HTTPS or some other mechanism.
> 
> draft-ietf-netconf-zerotouch-04 uses these kinds of mechanisms to provide data, where you instead sign the configuration data that can be downloaded through insecure means, but you won't use it until you've verified its authenticity (for instance by doing lookups using DNSSEC to get certificate ID or similar).
> 
> I also would like to separate the mechanism(s) how the information is transmitted and what information we want to transmit. These discussions are very different, and the mechanism how to transmit the information is probably not going to be changed that much, whereas we might want to add information we want to transmit more frequently.
> 
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se_______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif

v2.23.0 | Report a Bug | By Email