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

[Brian E Carpenter <[e-mail]>]

On 06/07/2017 19:09, Toerless Eckert wrote:
> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote:
>> It used to be, but the recommendation today is a pseudo-random
>> value (RFC7217). In any case it's a software choice.
> 
> brand new recommendations do not equate to be expected
> standard practice in products. Would be very good to have
> folks with practical insight into various products to 
> provide more information.

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.

> 
>>> 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.
> 
> If you have an L3 switch with 48 ports, likelyhood that it will
> not have 48 different MAC addresses is very high.

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.
 
>> In fact, the only way they could have the same LL address is
>> by manual configuration.
> 
> I do not believe that to be true from past product experience.

I think the confusion is that because of the L2 bridge function,
all those 48 interfaces behave as a single interface viewed from L3,
and therefore naturally have the same L3 address. So if the L3 code
in the switch itself also sees them as a single interface, we have
no problem. If the L3 code can see 48 separate interfaces, we do
have a problem.

(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.)

(There is more complication potentially caused by VLANs.)

> 
>> 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.
> 
> 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/

> 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.

    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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>