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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 08 July 2017 02:00 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 01021131472 for <anima@ietfa.amsl.com>; Fri, 7 Jul 2017 19:00:26 -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 h5TAZUxOoQm1 for <anima@ietfa.amsl.com>; Fri, 7 Jul 2017 19:00:23 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 85E3A129B16 for <anima@ietf.org>; Fri, 7 Jul 2017 19:00:23 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id j186so24721751pge.2 for <anima@ietf.org>; Fri, 07 Jul 2017 19:00:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=Zn1+ETFb9PxXVwSmcRTBiqRoX1Vi13rA00h1YMwVWok=; b=o11XUHbUY8e7cCHjmO2/l7FjbmZJzoIy5RRFfvenYQeo0zSIhQgLvd2osLuNqj7eGT QjcXv3SvZddA3VLcFfK0JcfGseHIfTPNRxdOcUG3F8lDyMCsmwGKHdp7zHU844Cb7WxQ mgqTpUkxYhpnw3CaQ8MlGahgyq+g5j1/1AwFBnwq3La1PVFTqVyuWsLeeR2b4lE9I3NY e3krIy3MNCsQ4NfeVcML/zq/ia6rFXVjcRF9YGUGFEVbMMeTn63hsLs6d4I1W69bLVlZ 8yy3cjIOFRku4KMkaYLRNS8PAUz+YzxMlYx5oqMtZc/+aEy8jD+/FNf16tVWhpB2Cicd mv0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=Zn1+ETFb9PxXVwSmcRTBiqRoX1Vi13rA00h1YMwVWok=; b=qcef/2p1PFi7ERQ1/oU7SDJCzVyVuuqeoMPoHJMTDNO47SlNRm6T9JrL0e4YBB2SAR f6tBrOOdIlvWVKpGNZMioJ9mnZsEZkvzGmSmB8u8oUjUp4t++8z4eo5eZEmxbeavQ/z1 +g0P3znhv9r7Ljz2uMeR3trSNvgWtRXB0Xk048bnK/8RzH6TuU0KO+nS7nAZqV0BsRfx PwwUHQAwhDPnnaDxEZDqI6Vr0W6F3PAYk8apk2P3WWckULEd4AeoH4R+m1KsZY0iJscs kyH13geqoe1Qf4zsh9L2+PKj9K6u3tyBhaX5tLcA2rnM827Wg7xcjmrOTJCLofFNho7v G5SQ==
X-Gm-Message-State: AIVw113swxQHA10ivmZ73NJycqE5rjvXgTFSIfyncm/Fi+GxXhqJfonH 6wbypQJ0ayZPlU7C
X-Received: by 10.99.53.129 with SMTP id c123mr4155798pga.87.1499479222109; Fri, 07 Jul 2017 19:00:22 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n71sm9969162pfi.95.2017.07.07.19.00.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 19:00:21 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: Anima WG <anima@ietf.org>
References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <a4682428-a385-4307-6fcf-ffdd4e04d8f5@gmail.com> <20170706231400.GB24940@faui40p.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <e1e8f3e2-f523-5255-09ea-2bb7daec4403@gmail.com>
Date: Sat, 08 Jul 2017 14:00:29 +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: <20170706231400.GB24940@faui40p.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/dqdLGDzF3aqHSx0KCWr6r_rFM00>
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: Sat, 08 Jul 2017 02:00:26 -0000

And for those who aren't on v6ops, the answer is clear:

Although for classical host o/s I'm correct, and the norm is
to have a different link-local address on each interface,
a) this is not required by the IPv6 standards, and
b) on L2/L3 switches from major manfacturers, it is common
that many interfaces have the same link-local addresses.

Which means that my diagram should be:

                   ___________
                  | REGISTRAR |
                  |___________|
                        |Ar
                        | 
                   ...........
                  (    ACP    )
                 (   routing   )
                  (   cloud   )
                   ...........
                        |
                        |Ax
                   _____|_____
                  |   PROXY   |
                  |___________|
                   |Lx       |Lx
                   |         |
                   |         |
  -------LAN1---------      -------LAN2----------
      |                                     |
      |Lp                                   |Lp
  ____|____                              ___|_____ 
 | PLEDGE1 |                            | PLEDGE2 |
 |_________|                            |_________| 

That means that packets from PLEDGE1 and PLEDGE2 to the proxy
could have 100% identical addresses. So straightforward IP-in-IP
to the registrar will not work, because the registrar would
have no way to distinguish them, and the proxy would have
no way to distinguish the replies. Maybe the port numbers
offer a solution but they are in the embedded payload.

Michael R, help!

Regards
   Brian

On 07/07/2017 11:14, Toerless Eckert wrote:
> Ok, sent mail to v6ops, not cc'ed to anima (though shall not group-cross-post IETF policy *sigh*).
> 
> More inline.
> 
> On Fri, Jul 07, 2017 at 08:32:03AM +1200, Brian E Carpenter wrote:
>> Indeed. But the general-purpose o/s stacks (I mean Linux,
>> MacOS and Windows) have been using pseudo-random interface
>> IDs for several years, since long before RFC7217. If you're
>> talking about L2/L3 switches, I have no idea.
> 
> Yeah. Especially MacOS and Windows are widely deployed router OSs ;-))
> 
>> Yes, because it is *also* an L2 switch, a.k.a. a bridge, so naturally
>> it appears as a single L2 device. So this depends on its internal systems
>> model. This is the kind of complexity you get with layer violations,
>> and an L2/L3 switch is the king of all layer violations.
> 
> Its got less to do with layer violation and L2 switches but rather with
> the cost of a large number of MAC addresses. Those have to be paid for.
> Primarily so that people do not exhaust them too quickly. Like when
> you would uhmm... assign a separate MAC address to every bloody L3
> network devices subnet ;-)
> 
>> (There is a complication in the switch caused by optimisation for
>> multicast, because MLD snooping has to look at both L2 and L3
>> headers. But BRSKI proxying only has to look at L3.)
> 
> Only stupid MLD snooping needs to look at L2, but most MLD snooping is stupid ;-)
> 
>> (There is more complication potentially caused by VLANs.)
> 
> Indeed, i forgot. By default, multiple L3 subnets on a single physcial
> ethernet will very often get the same MAC address. And it's quite
> common for a router to just have such a trunk L3 interface.
> 
>>> I just meant that a second link-local address could solve the
>>> problem if multiple interfaces have the same link-local address.
>>
>> s/multiple interfaces/multiple L3 interfaces/
> 
> "subnets" in IETF lingo ;-) or "read what i mean" ;-)
> 
>>> We should move this discussion to v6ops to get feedback from folks
>>> with more insight - once we get a better understanding why some
>>> UDP encap would not be the more logical option. Just because i may
>>> not have link-local address issues does not mean that IPinIP gives
>>> me the degree of lightweight impleemntation options i would like to
>>> have (at app level).
>>
>> Agreed. IMNSHO this is not cooked yet and should not be mentioned
>> in a standards-track draft unless we want a very long discussion
>> with the IESG.
> 
> Yes
> 
> Toerless
> 
>>     Brian
>>
>>>
>>> Cheers
>>>     Toerless
>>>
>>>>> 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.
>>>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index )
>>>>  
>>>>> 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.
>>>>
>>>>     Brian
>>>>
>>>>> 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
>>>>>> Anima@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>
>>>
>