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

[Toerless Eckert <[e-mail]>]

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.

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

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

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

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

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

-- 
---
[e-mail]