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

[Toerless Eckert <[e-mail]>]

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

I have not found evidence of being able to have multiple link-local
addresses on an interface. 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 ]

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.

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

-- 
---
[e-mail]