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

Toerless Eckert <tte@cs.fau.de> Mon, 17 July 2017 16:32 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 DD831131CAC for <anima@ietfa.amsl.com>; Mon, 17 Jul 2017 09:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 CF-aTSI4JrWJ for <anima@ietfa.amsl.com>; Mon, 17 Jul 2017 09:32:41 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5B2131CAA for <anima@ietf.org>; Mon, 17 Jul 2017 09:32:40 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C222258C4CB; Mon, 17 Jul 2017 18:32:36 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 91251B0C5EF; Mon, 17 Jul 2017 18:32:36 +0200 (CEST)
Date: Mon, 17 Jul 2017 18:32:36 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Eliot Lear <lear@cisco.com>, Anima WG <anima@ietf.org>
Message-ID: <20170717163236.GA30196@faui40p.informatik.uni-erlangen.de>
References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> <ac374936-2718-c737-e871-e9f97ea6f78a@cisco.com> <11013.1500281740@dooku.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <11013.1500281740@dooku.sandelman.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/81OwPER9ckmDwmCqbqSMTk-YYS8>
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: Mon, 17 Jul 2017 16:32:43 -0000

I think.... *righ*... eg: The only clean way with IPinIP is that every proxies
subnet can be distinguished on a registrar by the encapsulation header of IPinIP
and that only has source and destination ACP ULA addresses, yada yada: we need
either more ULA on the proxy and/or the registrar. 

I guess we do not want any on-demand actions on the proxy because that would be
a dynamic state establishment that we try to avoid, so the proxy would need
to set up all the state needed upfront which means it needs one IPinIP tunnel
per subinterface, just at the off-chance that some pledges have the same address.

So then we look at the total address waste and obviously we may have 1000 pledges
but 1 or few registrars, so it definitely would make most sense to get these addresses
on the registrar, announce via GRASP and let pleges build tunnels with them.

And the registrars would dynamically build these tunnels based on (Src,Dst) encap headers
received, and hopefully somebody comes up with a better way for linux to do this than
loosing the first packet which seems to be what Michael is running into.

And given how the tunnels ultimately are built only on a (per-proxy,interface)
basis there is also not a direct attack vector against dynamic creation based
on nasty pledges.

So, i am warming up more to this ;-)

Cheers
    Toerless

On Mon, Jul 17, 2017 at 10:55:40AM +0200, Michael Richardson wrote:
> 
> Eliot Lear <lear@cisco.com> wrote:
>     > On the other hand, maybe it's fundamental, but is relying on LL in this
>     > architecture to go beyond LL boundaries the right thing to do?
> 
> We've already established a way around the concern that made me think
> that we needed multiple LL for the proxy, and also that we needed multiple
> Ar for the proxy connection.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
tte@cs.fau.de