Subject: [IPsec] Multi-access interfaces (with IPsec)

From: Toerless Eckert <[email-masked]>
Date: Sat, 5 Aug 2017 01:37:10 +0200

I want to describe (in some draft) the use of a virtual multi-access
interface that is mapped to multiple p2p associations (eg: IPsec). 
Which i think is a pretty standard option in industry implementations, eg:
in hub routers for hub & spoke deployments.

Is there any good RFC reference that explains how this works, eg:
replicate ll-multicast to all p2p associations, learn peer addresses
from received packets or specific IPv6 signaling packets, use that
to send unicast into right p2p association, etc. pp.

I could not find a good reference RFC for this ;-(

Thanks!
    Toerless

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Aug 2017 12:40:21 -0400

Hi,

Not really sure what exactly you are looking at, but these links might be
helpful.

Yours,
Daniel

https://tools.ietf.org/html/rfc7791
https://tools.ietf.org/html/rfc7018
https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03
https://tools.ietf.org/html/draft-detienne-dmvpn-01

On Fri, Aug 4, 2017 at 7:37 PM, Toerless Eckert <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: te36 <[email-masked]>
Date: Mon, 7 Aug 2017 20:38:44 +0200

Thanks Daniel!

Quick browsing does not seem to show that these docs discuss what i am looking for,
so let me explain it hopefully better:

Assume i have a p2p subnet with two routers attached. I want to use IPsec
to protect all IPv6 traffic on that subnet and make it "invisible" to all
IP protocols as much as possible. So i set up an IPsec SA between the two
and set the SPD on both sides to protect all traffic. 

So this will work fine, and i vendors are supporting it, but i am not aware
of an RFC specifying this. For example, what would you put into the Link-Layer
address option of IPv6 ND packets. I assume this would be the underlying
link-layer address (eg: ethernet address), but thats not 100% obvious.

So, thats the simple case. Lets consider now i have 3 (or 30) routers on a LAN and
want to protect it with IPsec. Usually, i could not create multiple SAs
across a single interface (from what i have seen in products). There are
products that allow you to create a virtual IPsec subnet, but those are p2p,
eg: you create a full mesh of SAs and on every router you see two separate
virtual IPsec p2p interfaces, each operating the same as the above p2p example,
except that the implementation might be different.

But i would rather like to see a single multiaccess subnet interface on each
router so that i can fully reflect the underlying topology. And any protocols
using multicast would continue to operate. Its not really that difficult,
as i already said in my first email:

  - Replicate multicsts into all SAs. Including ND multicasts.
  - You keep a mapping table about which IPv6 nexthop belongs to which SA.
  - Send unicast into the right SA based on that nexthop table.
  - Populate that nexthop table from source IPv6 addresses
    received from each SA. Maybe limited to received ND packets.
  - Continue to populate the the underlying Link-Layer address, but 
    no need to maintain any link-layer mapping table (send but ignore on
    receipt).

And now i just wonder if i need to write this down into my draft, or if i can
find some existing RFC (or draft) i could refer to. Especially because the details
of learning the SA mapping are pretty arbitrarily. Eg: I think it would logically
be a lot better to have SPIs as link-layer addresses, but i wouldn't want to
invent something new just because i think it's logically better. Or i
populate the mapping table solely from the peer address of the SPI (eg:
link-local-IPv6-address of the peer on the SA).

The definitions i am looking for does not need to be specific to IPsec. The
problem is IMHO quite orthogonal to IPsec. Eg: instead of IPsec SA, i could
equally try to protect the traffic with any other form of secure p2p tunnel.
But i wouldn't know which other IETF mailing list to ask for other contexts
(suggestions welcome).

There is for example rfc7847, but it has a lot of surplus (;-) mobility stuff
in it, and it doesn't tackle the simple points of multicast, how to learn
next-hop mapping , eg: what to do with ND packets, etc. pp, so i think it
wouldn't help me as a reference.

Cheers
    Toerless

On Mon, Aug 07, 2017 at 12:40:21PM -0400, Daniel Migault wrote:
> Not really sure what exactly you are looking at, but these links might be > helpful.
> 

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Aug 2017 09:56:58 -0400

> link-layer address (eg: ethernet address), but thats not 100% obvious.

I have no idea why you would asking that question.
What link layer are you speaking about?  It's just IP inside the tunnel.
Why would there be ND inside the tunnel?  It's a PPP tunnel.

    > except that the implementation might be different.

Yes.

    > as i already said in my first email:

The reason you don't see such a specification is because it isn't specified.
While we have some multicast key management protocols for IPsec, they aren't
aimed at securing a subnet.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: te36 <[email-masked]>
Date: Tue, 8 Aug 2017 18:52:15 +0200

>From rfc4861:

  point-to-point - a link that connects exactly two interfaces.  A
                    point-to-point link is assumed to have multicast
                    capability and a link-local address.

   point-to-point - Neighbor Discovery handles such links just like
                    multicast links.  (Multicast can be trivially
                    provided on point-to-point links, and interfaces
                    can be assigned link-local addresses.)

But also remember that the original spirit of  rfc4301 (i hope i state this correctly)
is not that of "tunneling", but rather of authenticating/encrypting packets. This
is reflected in the SPD that allows you to specify some subsets of packets to
which you apply this security. So address resolution itself would in most traditional
implementations (at least the ones i know) still see the underlying type of interface
and use its address resolution method and formats (eg: Ethernete, ARP/ND, 
ethernet address).  Thats of course exactly what i find non-ideal in what we want
to do, hence also my question about a "virtual interface" definition.

> aimed at securing a subnet.

Ok, thanks for confirming that there is no specification utilizing IPsec.

There could still be some RFC specifying how to build a virtual
"pseudo-multicast" enabled "NBMA" subnet using a bunch of underlying
 p2p subinterfaces and how to ND in that case. So maybe i should ask on 6man.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Aug 2017 20:15:44 -0400

> and use its address resolution method and formats (eg: Ethernete,

It's a great thought, but it's not implemented for reasons that wind up
devolving into "we don't have a global PKI", (with a bunch of "the customer
didn't ask for that" in the middle)

    > p2p subinterfaces and how to ND in that case. So maybe i should ask on

RFC6550 is such a specification.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-