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

["Max Pritikin (pritikin)" <[e-mail]>]

re: "this case must work”
There sure is a lot of complexity in this thread to ensure that link local addresses can be used outside of the local scope. 

Some simpler suggestions,

1) a stateful proxy. I know, I know. But how many devices are actually going to need to perform BRSKI at the same time? And if that many devices are being bootstrapped then can’t they wait for the proxy to work through them in order? 

2) Require pledges to complete RFC4862 ‘Creation of Global Addresses’. Pledges then perform GRASP and then communicate with the Registrar directly. (Can RFC4193 ‘Unique Local IPv6 Unicast Addresses’ be assigned? I think so…)

or 

3) If it *doesn’t work* what happens? Currently BRSKI starts over w/o stating anything about obtaining a new Lp. Would it help to restart the stack and look for a unique Lp at that point? All we’re looking for is non-collision during bootstrapping. I don’t like this approach as much as the above options. 

- max



> On Jul 5, 2017, at 8:19 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Hi BRSKI authors,
> 
> 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.
> 
> 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.
> 
> 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