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

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

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