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

Brian E Carpenter <> Thu, 06 July 2017 04:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 959B21243FE for <>; Wed, 5 Jul 2017 21:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id urBojgNd3Wae for <>; Wed, 5 Jul 2017 21:34:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 770F812FB9A for <>; Wed, 5 Jul 2017 21:34:03 -0700 (PDT)
Received: by with SMTP id q85so5017368pfq.1 for <>; Wed, 05 Jul 2017 21:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rxRB8aglw8PAqNON/lEdn0ptyOTvD01wD34D8Wvw87I=; b=pXn9U6wN1E5jsB/hWFTcrD7pHfLaHTPt89RgyCDOPAkkEdgoucWMkdMTtK5DUzfVZF hs+Of4aa/+Y75yLyAu33o+1I0D47qFwkhbyv2tTcVmRCIKuoAH9ggjS+toV9nQQca9WR CSYAFZdh06aWgpRvc+TNuViyr6LF0Cctd5/jPcYvZrw5t3aaJ8+OX+/tgPwSPg5EqCpX DWzvUwaQaL1McOuB+QoAFixPVViDF0daQFWki6vPNaGw8Or2I5r+m78uckGZ92U413nh 4iZGCHjA3Bv5LEaG9kwf1lFn5dPsLI+5/+gtD7JreAMGYYV4ejkScuFNblcJ3aaXOy06 UVLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rxRB8aglw8PAqNON/lEdn0ptyOTvD01wD34D8Wvw87I=; b=OKP7WDELMwLwx5Ksqt2yZ+OKz47eT2kZfIUjnmjxXudorKamsbqWqcSP7hp4CdnoPc D5ZyOg+ZUJt11bZ0it9KSGd28NAQIw0oZpTljXt9ez0bD5slOaw2Ryp15/Uidm9QvGxN IPuW8Ooy6CSva/PgRvSUsODbKQTtmilJZKOGJY94BNWb1KRlND7bBQY9hB82waroaGUs af+uaBAHQb7gVVKRYA6bxHB1cfhkVjldqN5VYRspn7kcRwW6RPk39xfh5Ro5sl09eoOM ZHzE1SS8kygF4+46ngWxuaF4QF+A0/9FNSljAQTfAL25ZGInzCBf5G7Lr9ZQt2B1OZU2 Gi/Q==
X-Gm-Message-State: AIVw113/aj9K7UwruNtQTrlvwFzB/04dNJ39CfHIty4R0el1LPn2eZxo y85ljjpTvky53hCu
X-Received: by with SMTP id s18mr24437934pgd.113.1499315642739; Wed, 05 Jul 2017 21:34:02 -0700 (PDT)
Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by with ESMTPSA id s62sm1343178pfi.36.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 21:34:02 -0700 (PDT)
To: Toerless Eckert <>
Cc: Anima WG <>
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 06 Jul 2017 16:34:05 +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: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] Is this how BRSKI/IPIP works?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jul 2017 04:34:06 -0000

On 06/07/2017 15:37, Toerless Eckert wrote:
> On Thu, Jul 06, 2017 at 02:19:23PM +1200, Brian E Carpenter wrote:
>> Hi BRSKI authors,
> Can i still answer ?
> Inline. I only have an ACP author, WG chair and general bloviator hat though...
>> Is the following correct?
>> Topology (ASCII art):
>>                    ___________
>>                   | REGISTRAR |
>>                   |___________|
>>                         |Ar
>>                         | 
>>                    ...........
>>                   (    ACP    )
>>                  (   routing   )
>>                   (   cloud   )
>>                    ...........
>>                         |
>>                         |Ax
>>                    _____|_____
>>                   |   PROXY   |
>>                   |___________|
>>                    |Lx1      |Lx2 
>>                    |         |
>>                    |         |
>>   -------LAN1---------      -------LAN2----------
>>       |                                     |
>>       |Lp                                   |Lp
>>   ____|____                              ___|_____ 
>>  | PLEDGE1 |                            | PLEDGE2 |
>>  |_________|                            |_________| 
>> Assumptions:
>> Pledges have link-local address Lp. By chance, they are equal. (Nothing in
>> the standards prevents them from being equal. Even pseudo-random numbers can
>> be equal, so this case must work.)
>> Proxy has link-local addresses Lx1, Lx2 and ACP address Ax. We can require
>> that Lx1 != Lx2.
> No, i think we can not. AFAIK, it is common practice to put
> your MAC address as the host part into link-local addresses

It used to be, but the recommendation today is a pseudo-random
value (RFC7217). In any case it's a software choice.

> and only high-margin network equipment vendors
> afford ranges of in my experience at most up to 8 MAC
> addresses to a single device. And you do not want to 
> make a protocol that changes any current possible
> and likely practices. 

We're talking about different physical interfaces. Normally they
will have different MAC addresses, if they still use the old-fashioned
method, or different pseudo-randoms if they follow RFC7217.
In fact, the only way they could have the same LL address is
by manual configuration. So I stand by what I said: we can require
them to be different, and in practice they will be different anyway,
on all conforming IPv6 stacks.

> I have not found evidence of being able to have multiple link-local
> addresses on an interface. 

No, but that is not the scenario. My diagram shows two different interfaces.

> But even if that was architecturally permitted,
> it too would likely not something you could easily do through
> a non-privileged app via UDP socket API (i fear). This concern may be
> bogus because the registrar would already need to deal with IPinIP,
> which is no fun for a non-privileged app without OS support.
>> Registrar has ACP address Ar.
>> Packets for a UDP example:
>> (somewhat simplified IPv6 packets!)
>> Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1]
>> Proxy sends to Registrar [Ax, Ar, 41, [Lp, Lx1, 17, UDP-PAYLOAD1]]
>> Registrar replies to proxy [Ar, Ax, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]]
>> Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2]
>> Note that the registrar echoes back the addresses Lp and Lx but they mean
>> nothing to it. The registrar simply borrows the proxy's LL address Lx
>> for the purpose of replying.
> Not quite "means nothing to it".
> The registar will have to build connection state and the connection key is
> [ Remote_vIP=(Lp, Lxi, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ]

Right, but it isn't used as an IP address on a real interface.

> Given how my claim is that multiple Lxi may be the same AND that as
> you already said, Lp may be the same, we need another field to
> distinguish those connections.

If that was a real problem, which I don't think it is, we would have to
include the relevant interface number as used inside the proxy's stack.
(There's a horrible trick used only in the FreeBSD stack to do this, by using
some of the spare bits in a link local address for this purpose. )
> C.1 of BRSKI suggests to allocate more addresses, eg: multiple Axi.
> But given how ACP addresses are backed by certificate, its not as 
> easy to get more ACP addresses as it would be in less secured
> transport substrates.
> Solutions:
> I would change the encap from IPinIP to some UDP header variation:

Yes, while I was studying this I wondered why not just use IP-in-UDP.
It still allows the proxy to be dumb.

I'd like to hear from Michael Richardson on all this. Again, my goal
is to understand enough that we can get the representation in the GRASP
objectives right.


> I want to be able to implement pledge, proxy and registar as
> simple apps using just UDP sockets. Thats something i can implement
> anywhere i want. 
> Unless someone comes up with some pre-existing encap that makes
> life easy, i would just make the proxy insert a link-local
> pseudo header between the UDP header and the original pledges UDP payload.
> pseudo header would need to contain (Lp). Then in addition,
> the proxy would need to open a separate UDP socket for each local
> interface it has. That would make all UDP packet from proxy use a separate
> RemotPort on the registrar. The benefit of this approach is that i could
> start separate ASA, one for each interface, and if one interfaces proxy
> is attacked by pledges, it will not have an impact on other interfaces.
> And i minimize unnecessary headers.
> Relevant connection key is then:
> [ Remote_vIP=(Lp, Ax), Local_IP=(Ar), Proto=17, RemotePort, LocalPort ]
> Aka: Lxi is irrelevant and can be ignored by registrar.
> Given how this is not a throughput relevant proxy function i do not
> care avbout the fact that i must recalculate UDP checksums over the
> packet (something that has bothered UDP tunneling solutions in the IETF
> for years now).
> Cheers
>     Toerless
>> Note that even the 2uple {Ax, Lp} might not uniquely identify the pledge.
>> Since the proxy will have at least two interfaces, the address Lp might
>> exist on multiple LANs. However, the proxy will have different link-local
>> addresses on the two LANs, so the 3uples {Ax, Lp, Lx1} {Ax, Lp, Lx2}
>> will be unique. Hence the registrar can distinguish the transactions.
>> So, what the registrar needs to tell the proxy is: I accept IP in IP on address Ar.
>> Nothing else - no port number, no link-local address.
>> What the proxy needs to tell the pledge is: I accept BRSKI/TCP
>> or BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact
>> the registrar, it simply forwards the packets as-is in both directions,
>> encapsulating and decapsulating accordingly. The pledge knows nothing about
>> IPIP.
>> Regards
>>    Brian
>> _______________________________________________
>> Anima mailing list