Just in case someone missed my first 10 opinions: UDP encap. Also allows to build pledge,proxy.registrar as normal socket apps.
On Sat, Jul 08, 2017 at 02:00:29PM +1200, Brian E Carpenter wrote: > And for those who aren't on v6ops, the answer is clear: > > Although for classical host o/s I'm correct, and the norm is > to have a different link-local address on each interface, > a) this is not required by the IPv6 standards, and > b) on L2/L3 switches from major manfacturers, it is common > that many interfaces have the same link-local addresses. > > Which means that my diagram should be: > > ___________ > | REGISTRAR | > |___________| > |Ar > | > ........... > ( ACP ) > ( routing ) > ( cloud ) > ........... > | > |Ax > _____|_____ > | PROXY | > |___________| > |Lx |Lx > | | > | | > -------LAN1--------- -------LAN2---------- > | | > |Lp |Lp > ____|____ ___|_____ > | PLEDGE1 | | PLEDGE2 | > |_________| |_________| > > That means that packets from PLEDGE1 and PLEDGE2 to the proxy > could have 100% identical addresses. So straightforward IP-in-IP > to the registrar will not work, because the registrar would > have no way to distinguish them, and the proxy would have > no way to distinguish the replies. Maybe the port numbers > offer a solution but they are in the embedded payload. > > Michael R, help! > > Regards > Brian > > On 07/07/2017 11:14, Toerless Eckert wrote: > > 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 > >>>>>> [email protected] > >>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>> > >>> > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
