Re: [Anima] Is this how BRSKI/IPIP works?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 12 July 2017 20:55 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8412ECED for <anima@ietfa.amsl.com>; Wed, 12 Jul 2017 13:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KdpBsAuc242e for <anima@ietfa.amsl.com>; Wed, 12 Jul 2017 13:55:01 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 636FF126B6D for <anima@ietf.org>; Wed, 12 Jul 2017 13:55:01 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id q85so18518087pfq.1 for <anima@ietf.org>; Wed, 12 Jul 2017 13:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z0LW9kb22fgJrXTM0o17zUXVt5Ltr/GYsGYQxqGV2AU=; b=eNwZtnnq+NsStvTpb6BZSoY4Vr1Iww/GqTMb9PkPVF3nLdixxEPEBGvR2ky9ts4RJy P+ur8Jo2i8sbUTIYiCBzlDfvuyvyXYYkqzU/4qcqRE+ctjquCB1kMW7HAEE6P9QqmuDl YgtYoqW7ICeMqJ1f3xWzSNHkQAl/W7Y9c6BJxrHSo+aM9xbPurZFO2UfL+pgO/ZXVZc0 9M1R+aZXUesCG2/kMcyw7d9cIb/cuMwxUCIMob51B2BXywa0HZ1lols21TVaVhs07nTE Z+1GLBmpxsKETibFDjTFFa/1x1feaDm2D2x8JkKHqW4/9ICfQyFr0WsvZ3Fl2BcW+UNu WbVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=z0LW9kb22fgJrXTM0o17zUXVt5Ltr/GYsGYQxqGV2AU=; b=MYTsZDusRM023SP40/zpqJwA0qUB4ggp04mf41bYAv9sMEisnXt6jfeDCXG4QqKgFQ b7VnwhiZtlBy3t40e1FLxTf0HtA117jwShrXf5DWUt4q08zZzD6OvRh27f3orAcDCh4A bUgfUst9Y770yCHwohYAOr4QHTvxoQcNf89PoflOm+I+vGKK7mQQLXhiMV49jCqkc/al xafRheCmxwdTEiJR50ZrhBnivyzrL4ct1ruvWyE6omymYGJy+7FbciQLR0wecwy44vzk rfeNilLpk1l6VMEU7Q2m+5LsKIpsIiJ1nko29zIiZY2KlLMPguJcRTegHxsSfz08rlpr Jqtg==
X-Gm-Message-State: AIVw110Gs6Ff8X/Ecqs/pnIDrRjDGIEgM23sv7ADkdDZ0iNEFRauEKJL J3uhB5pw1EYPeNTH
X-Received: by 10.98.70.86 with SMTP id t83mr56877410pfa.219.1499892900606; Wed, 12 Jul 2017 13:55:00 -0700 (PDT)
Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id 70sm6911119pft.104.2017.07.12.13.54.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 13:54:59 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>
References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com>
Date: Thu, 13 Jul 2017 08:55:02 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <25643.1499875039@dooku.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/eWadAbd3MbeoXO5ov9drSBONjWw>
Subject: Re: [Anima] Is this how BRSKI/IPIP works?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jul 2017 20:55:04 -0000

OK, I'm getting there. More in line:

On 13/07/2017 03:57, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     >> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > Is the
>     >> following correct?
>     >>
>     >> > Topology (ASCII art):
>     >>
>     >> Topology is essentially correct.  As you point out, RFC7217 is the
>     >> recommendation going forward, so having a a big IEEE OUI allocation
>     >> isn't necessary anymore.
>     >>
>     >> But, the problem is you have a single Ax for the device.  The ACP
>     >> needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc.
> 
>     > Yes, that would disambiguate it. But in general it isn't necessary for
>     > a node to have multiple ACP addresses just because it has multiple
>     > interfaces, is it?
> 
> We need a way to distinguish the different links (and scoope of the LL
> address) in a way that can be communicated easily and cheaply to the
> Registrar.    I've asked for the "V"irtualization bit to be bigger, and I see
> no purpose for the Zone-ID myself.
> 
>     >> That's why I wanted a /96 or so provided by the ACP to each device.
> 
>     > That would be one way, but it will create noise in 6man.  In any case
>     > if the requirement is one address per proxy+interface I'm sure it can
>     > be done somehow; IPv6 addresses are cheap.
> 
> It's not a subnet for the device to announce, it's a large bag of /128s.
> 
>     >> Instead, I have two suggestions, not entirely mutually exclusive: 1)
>     >> the Registrar says, "I accept IPIP on Address Ar, use Lr for
>     >> connections"
> 
>     > I don't understand where Lr would be used. The LL messages are all
>     > between the pledge and the proxy, which have perfectly fine LL
>     > addresses of their own.
> 
> Assume a TCP connection from the Pledge to the Registrar.
> It looks like, as you wrote:
> 
>    Pledge sends to proxy [Lp, Lx1, 17, TCP-PAYLOAD1]
> 
> On the registrar, when it emerges from the IPIP tunnel, this is what the
> registrar sees.   If we do nothing, the Registrar says, "Lx1"? What's that
> it's not me. Drop.  So we have to do something. Options are:
> 
> 1) Registrar accepts any Lx1 as local.
> 2) We pick a well-known Lx value (a LL anycast).
> 3) We have the Registrar tell the proxy an Lx value to use.
> 
> 
> 1) Registrar accepts any Lx1 as local.
>    There is no precedent in v6 APIs to open such a socket, but this actually
>    supported on many platforms.  It's used for nasty stuff like transparent
>    application layer proxies, forced HTTP proxying, and the like.

I think there's a more subtle way to look at it. When the registrar receives
a protocol 41 packet from a new ACP address, it conceptually synthesises
a new virtual interface and assigns Lx1 as its link local address. On
that interface, things would look normal. Thus RFC2473:

>>  The tunnel link-layer input and output can be implemented similar
>>  to the input and output of other link-layer protocols, for
>>  instance, associating an interface or pseudo-interface with the
>>  IPv6 tunnel.

I really think this is a clean approach. In any case, what happens to
a protocol 41 packet is always a bit strange and is not covered by
the traditional socket model.
> 2) We pick a well-known Lx value (a LL anycast).
>    The pledge has to do something slightly funky where it forces a particular
>    L2 address for the anycast LL, because if there are multiple proxies on
>    the network, straight ND will get one at random, and the Pledge actually
>    wants to be specific about which one it uses. (since it wants to try them all)

How can it work as anycast if is more than one proxy on the LAN?
I'm not at all clear that anycast under fe80::/10 makes much sense.

> 3) We have the Registrar tell the proxy an Lx value to use.
>    I chose to put this option into the protocol, because we can always
>    set Lx= Lanycast in the future, and perhaps we can set it to ::
>    if we want case (1).

I like this least of all. What happens if there are multiple registrars?
And when a proxy node comes up as a pledge, it must give itself a LL address
on each interface before it even tries to perform its own BRSKI, and before
it looks for its own proxy and joins the ACP. Is it supposed to change its
own LL address after it discovers the registrar? Or is it supposed to
have two simultaneous LL addresses? Is that even possible?
 
>     >> > registrar, it simply forwards the packets as-is in both directions,
>     >> > encapsulating and decapsulating accordingly. The pledge knows
>     >> nothing > about IPIP.
>     >>
>     >> It needs to know it's IPIP,
> 
>     > Why? The IPIP encapsulation and decapsulation can happen inside the
>     > proxy (and the registrar). Why does the pledge care?
> 
> Sorry. "Proxy" vs "Pledge"
> "IT" above referred to Proxy, but in fact it says "pledge". Typo.

OK!

> 
>     >> As for Toerless' notion that we should invent a new UDP-based
>     >> encapsulation
> 
>     > IPv6-over-UDP isn't exactly a new invention. It's been used in Teredo,
>     > TSP (RFC5572) and SixXs
>     > (https://tools.ietf.org/html/draft-massar-v6ops-ayiya-02)  More to the
>     > point, draft-ietf-intarea-gue is in progress.
> 
>     > All the same, if straight IPIP works, so much the better.
> 
> I resorted to using Ar as an additional signaling mechanism to "store" the
> ifindex where the request was coming from rather than try to find some bits
> in some other protocol like one you mention above.
> TSP is too complex for our needs.
> 
> Teredo has some space for additional stuff. It should be straight forward to
> define it over IPv6 rather than v4. Seems a bit weird to me though.

Yes. My point was only that this isn't uncharted territory.

   Brian