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

[Toerless Eckert <[e-mail]>]

Ok, sent mail to v6ops, not cc'ed to anima (though shall not group-cross-post IETF policy *sigh*).

More inline.

On Fri, Jul 07, 2017 at 08:32:03AM +1200, Brian E Carpenter wrote:
> 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.

Yeah. Especially MacOS and Windows are widely deployed router OSs ;-))

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

Its got less to do with layer violation and L2 switches but rather with
the cost of a large number of MAC addresses. Those have to be paid for.
Primarily so that people do not exhaust them too quickly. Like when
you would uhmm... assign a separate MAC address to every bloody L3
network devices subnet ;-)

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

Only stupid MLD snooping needs to look at L2, but most MLD snooping is stupid ;-)

> (There is more complication potentially caused by VLANs.)

Indeed, i forgot. By default, multiple L3 subnets on a single physcial
ethernet will very often get the same MAC address. And it's quite
common for a router to just have such a trunk L3 interface.

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

"subnets" in IETF lingo ;-) or "read what i mean" ;-)

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

Yes

Toerless

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

-- 
---
[e-mail]