Re: [Anima] RFC8994's IPsec tunnel description

[Michael Richardson <[e-mail]>]

{clearing out inbox}

Toerless Eckert <[e-mail]> wrote:
    >> I know that we did many rounds to get this right, but I feel that
    >> maybe we did it wrong.
    >>
    >> The goal are packets that look like:
    >>
    >> (a) IPv6-LL ESP[nh=41] IPv6-ULA[1] ULP

> What is "ULP" ?

If I didn't answer somewhere, it's "Upper Layer Protocol" (e.g., "TCP")

    >> The TS are "everything", so one in fact needs policy based routing on
    >> top of this in order to make anything work.

    > What you want to have is some form of virtual IPsec interface, which in
    > Cisco IOS was introduced in 2007, e.g.:

Yes, the kicker is how packets from that interface are fit into the PAD/SPD.
Ideally, they skip the PAD entirely, and have a (pair of) linked SPD (IPsec
SA) entries.  One for outgoing.  And the incoming one is linked so that
anything coming out appears to come out the Interface.  There should be no
enforcement of Traffic Selectors (TS).  I think Cisco got this right all
those years ago.

    > In Linux this is less clear to me. There where much later IPsec VTI
    > interfaces, but they seemed to have some limitations.

The VTI and XFRM Tunnel interfaces are seemingly identical in most ways,
except that VTI is created/managed by ioctl (which are a pain from languages
other than C), while XFRM Tunnel ocurrs via the NETLINK socket.

The problem that I see is that the packets still seems to go through the
PAD, when it really shouldn't.

    > Given how ACP is designed to support different secure channel option,
    > worst case we have to amend our stack with one more IPsec option, if
    > thats what's easier in Linux.  But it would be quite annoying if Linux
    > choose a different stack option than what commercial routers had for a
    > decade.

Agreed.

    > If on the other hand we made a mistake and didn't match what the
    > commercial router implementations use, then of course, we can obsolete
    > our currently documented option and replace it. But i don't think/hope
    > that that is the case.

WHen someone shows up with hardware that can't be used, we should have this
discussion.

I will attempt to put together some slides for 119 that address the ULA
addressing on the ACP DULL side that I am attempting to implement.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide