On Tue, Aug 08, 2017 at 09:56:58AM -0400, Michael Richardson wrote:
> te36 <t...@cs.fau.de> wrote:
>     > 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.
> 
> 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.

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

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

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

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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to