Subject: [rbridge] ARP proxying

From: huitema at windows.microsoft.com (Christian Huitema)
Date: Wed, 21 Dec 2005 12:49:49 -0800

> > 	In addition, since the RBridge enjoys a man-in-the-middle
position,
> > it is likely that implementers may well implement some hack or
another
> > to get around this.

SEND is explicitly designed to prevent this kind of hacks.
 
> There doesn't need to be a hack - though I expect that would be
> prohibited by the security model in SEND anyway. But SEND doesn't
> prohibit sharing the keys, which the rbridge could be party to.

Well, there is no explicit protocol to share the keys used in SEND. One
might argue that sharing these keys would in fact be a gross security
violation. The keys are cryptographically linked to the IPv6 address,
and could be used for many applications besides security the IPV6/MAC
address mapping. There have been proposal to use them for IPSEC and for
Mobile IP.

Now, we could question the value of securing the mapping between IP
address and MAC address in a switched/routed environment. After all,
even if the mapping was secure, the relays could still decide to rewrite
the MAC address, and deliver the packets to whatever point they feel is
appropriate. SEND can hardly provide a protection against that. One
possible outcome would be to recognize that SEND, as currently
specified, is not really secure.

In fact, we went through a similar analysis of the value of 802.1X
access controls for wired networks. In wireless networks, 802.1X
associates a MAC address with an encryption context on the access point.
But on wired networks, 802.1X only "authorises a MAC address", without
any further protection. Insert a hub on the path, and all kinds of
interesting attacks become possible.

The IEEE is working on a better solution for access control to wired
networks. It will probably involved some level of layer 2 encryption.
SEND probably needs to evolve in a same way. If it does evolve, then
there could be an additional requirement, i.e. accept the presence of
relays on path.

-- Christian Huitema

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 21 Dec 2005 13:10:38 -0800

And even without modifying SEND, it's possible to do a compromise 
optimization.
The totally nonoptimized thing is to flood the ARP/ND query, and have each
Designated RBridge decapsulate and send it on each of the links. The 
most optimized thing
is to have the first RBridge send the ARP/ND response to the querier.

An in-between
thing that works with current SEND (and probably any possible variation 
that it might
evolve into) is to have the first RBridge send the query to the target's 
designated RBridge,
who would send the query to the target, get a response, and send it back.

Radia

Christian Huitema wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 22 Dec 2005 09:33:07 -0800

Directing broadcasts as unicast (as suggested below) is probably a
better idea in general than replaying given security considerations.

Joe

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 23 Dec 2005 17:05:11 +0100

I agree with the idea of directing broadcasts as unicast (my proposal 
for ARP Servers/Registrars in Abridges draft also uses unicast), but I 
am a bit lost : How can the first Rbridge know which is the target's 
designated Rbridge if the destianion host'sMAC is unknown?. Perhaps I 
misunderstood something.
Guillermo
Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDquNTE5f5cImnZrsRAu9UAKCAHqIrk064jiQ0bd02O2NtVPBUzwCfQhzB
>/hm9XmTTp2h25Gn92MieJ3w=
>=fMOQ
>-----END PGP SIGNATURE-----

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 23 Dec 2005 09:07:07 -0800

Guillermo Ib??ez wrote:
> designated Rbridge if the destianion host'sMAC is unknown?.

That would be a 'cache miss', and MUST result in a broadcast. We're
still assuming an ARP cache at the DRs.

It's only under a 'hit' that a unicast can be provided.

Joe

---

From: ghutchis at gmail.com (Guy Hutchison)
Date: Sun, 25 Dec 2005 13:29:28 -0800

> there could be an additional requirement, i.e. accept the presence of

The IEEE layer 2 solution is standards 802.1AE and 802.1af.  1AE provides
hop-by-hop per-packet message authentication and optional encryption; 1af
extends 802.1X to work with the 802.1AE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051225/2be75482/attachment.html

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 29 Dec 2005 17:20:32 -0800

I guessed at the behavior once, to someone who was following 802.1 
better than I have
been, and he verified that I was correct at the time, but I've forgotten 
what my
conjecture was. Does anyone know how the following cases are handled?

Suppose a bridged network has some links configured
as VLAN A, and others configured as VLAN B, and some links that are not 
configured
as either VLAN A or VLAN B. Let's say that links La1 and La2 are configured
as VLAN A, links Lb1 and Lb2 are configured as Lb, and links Lc1 and Lc2 
are not configured
to reside in either VLAN A or VLAN B.

Let's further assume that it is the bridges that put on the VLAN tags.

What happens in the following cases?

a) A layer 2 multicast packet originates at La1. Certainly the first bridge
adds a VLAN A tag to the packet, and delivers the packet to La2. However,
does it also deliver it to Lc1 and Lc2? (I'd be very surprised if the 
answer to this
was yes...I assume the packet will ONLY get delivered to links that are
specifically marked as supporting VLAN A).

b) A layer 2 multicast packet originates at Lc1. I assume the behavior 
in this case
is that the first bridge does NOT add a VLAN tag to the packet. I can 
imagine either
in this case that the packet is ONLY delivered to Lc2 (i.e., other links 
that are not
configured as belonging to any VLAN), but I suspect the packet is 
delivered to
ALL links, i.e., in this case, La1, La2, Lb1, Lb2, and Lc2, and without 
a VLAN tag.
This would mean that endnodes in VLAN A and endnodes in VLAN B will see 
this packet, so
perhaps it's the other behavior (that it's only delivered to links that 
are not configured as being
in any VLAN).

c) If it is the bridge, rather than endnodes that put on the VLAN tag, 
is it legal for a link
to support multiple VLANs? It would make sense for the answer to this to 
be no, in which
case I suspect the answer to b) above would be more likely to be "don't 
deliver to any links
that have been configured to be in any VLAN", since I suspect "unmarked 
VLAN" is treated as a special
case VLAN.

Radia