IETF Logo Mail Archive

Re: [v6ops] Bar BoF on a 6to4 replacement?

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 13 November 2014 19:25 UTC

Return-Path: <iljitsch@muada.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 7E38A1ACD54 for <v6ops@ietfa.amsl.com>; Thu, 13 Nov 2014 11:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 n9Z0Xs7CS8W4 for <v6ops@ietfa.amsl.com>; Thu, 13 Nov 2014 11:25:39 -0800 (PST)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77C71ACDD4 for <v6ops@ietf.org>; Thu, 13 Nov 2014 11:21:56 -0800 (PST)
Received: from t2001067c03700176f5cf87abf6fbaf48.wireless-a.v6.meeting.ietf.org (t2001067c03700176f5cf87abf6fbaf48.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:f5cf:87ab:f6fb:af48] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sADJLfpo000593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 20:21:43 +0100 (CET) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <54643D0B.4070208@gmail.com>
Date: Thu, 13 Nov 2014 09:21:42 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com>
References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <AD4F3B9C-18D2-4B6F-867C-423368D6F489@muada.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <EB80E1B1-335F-45CA-BAFA-C2DB1BA58F1A@muada.com> <54643D0B.4070208@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QFAX7Bf93Q4TI8C98ujisjWJZBo
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Bar BoF on a 6to4 replacement?
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, 13 Nov 2014 19:25:42 -0000

On 12 Nov 2014, at 19:09, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

>> - Is requiring HTTP digest authentication problematic?

> Something I can foresee as a problem is sharing the keys, or do any encrypted or authenticated exchange, with someone who is on the other side of the globe, someone non-accountable in any particular way.  A matter of trust.

Yes, it would be somewhat risky to put the cloud credentials that give access to your entire digital life inside a $50 home gateway. So it would be good to require OAuth (RFC 6749). On the other hand, that could be quite a barrier for implementers.

However, I'd say that HTTP digest authentication is secure enough to protect an account that is only used to set up a tunnel.

>> - Is requiring DHCPv6 (the prefix delegation client role) problematic?

> I guess it is problematic.  I am not aware of any operator of DSL or cellular links that offers DHCPv6 Prefix Delegation service (a Server that replies positively to requests for prefixes).

It doesn't matter what the network operators do. If they provide native IPv6, then the whole effort is moot. What counts is what we can reasonably ask home gateway vendors to implement.

Iljitsch

v2.46.0 | Report a Bug | By Email | System Status