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

[Toerless Eckert <[e-mail]>]

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
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>>>
> >>>
> > 

-- 
---
[e-mail]