Subject: [rbridge] TTL only - was RE: New fields in shim header?

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 12 Oct 2006 12:06:45 -0700

Caitlin, 

See inline

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> Sent: Thursday, October 12, 2006 9:18 AM
> To: Silvano Gai; Joe Touch
> Cc: rbridge at postel.org; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> rbridge-bounces at postel.org wrote:
> > In today Ethernet I can write an ACL on the pair Source, Dest
> > MAC address, and many network managers find this extremely
> > useful, but I will not be able to do that on the RBridge
> > addresses, if I have only one.
> >
> > When an RBdridge receives a unicast frame, with the current
> > proposal it cannot screen it according to the ingress RBridge
> > and this is a big security hole. An Rbridge needs to be able
> > to drop traffic originated by another RBridge: this requires
> > two addresses.
> >
> 
> It can certainly do so with the current header. It merely has
> to map the source MAC address to the source RBridge -- something
> it would end up doing for the reverse packet anyway.

The source MAC address is much easier to spoof than the ingress RBridge
address, there is no guarantee that the frame entered the RBridge cloud
at the RBridge derived by the mapping you propose.

> 
> If the frequency of rogue RBridges is high enough to justify

The issue is not Rogue RBridges, the issue is that in a network there
will be RBridges that will connect unsecured hosts/links and the network
manager may desire an easy way to restrict them to a subset of the TRILL
cloud.

> a larger shim header to optimize dropping their packets then
> things are in a pretty bad shape. If there are network elements
> that cannot ultimately be physically disconnected by the network
> administrator then they should probably be separated by a router
> and not included in the subnet.

In today world, any tool you can give a network administrator to
segregate traffic is welcomed.

> 
> And given that any RBRidge header is not going to have IPSEC
> quality authentication the degree to which we can provide
> protection from a malicious RBridge is fundamentally limited.
> 
> Let's be realistic and keep security at the IP layer.

This is IEEE 802.1D replacement, there may not be an IP layer.

> The originally proposed short envelope solves the
> essential problems. The additional fields that Radia's
> recent draft suggested are all interesting. Many of
> them MIGHT help RBridges perform certain functions
> more efficiently. But I do not believe any of the
> extra fields are necessary, and my initial thought
> is that they do not justify eating away at the MTU.

I am much more concerned that TRILL will provide a superset of the
functionalities that 802.1D and all its variations provide, than saving
few bytes in the shim headers. I think the times where optimizing to the
last byte was important are long gone with 1 and 10 GE.

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 12 Oct 2006 12:29:25 -0700

Silvano Gai wrote:
...
> This is IEEE 802.1D replacement, there may not be an IP layer.

Agreed, but this is not an 802.1D _replacement_; this _supports_ 802.1D
functionality. It's not intended to overcome limitations - e.g., the
need for policy tags - that 802.1D lacks.

...
> last byte was important are long gone with 1 and 10 GE.

The only additional capability is supposed to be independent-path
forwarding, AFAICT.

As to "long gone with 1 and 10 GE", 802.1D also works at much slower
speeds, notably in wireless.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061012/29087d35/signature.bin

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 12 Oct 2006 12:41:58 -0700

Silvano Gai wrote:
>>> In today Ethernet I can write an ACL on the pair Source, Dest MAC
>>> address, and many network managers find this extremely useful, but I
>>> will not be able to do that on the RBridge addresses, if I have
>>> only one. 
>>> 
>>> When an RBdridge receives a unicast frame, with the current proposal
>>> it cannot screen it according to the ingress RBridge and this is a
>>> big security hole. An Rbridge needs to be able to drop traffic
>>> originated by another RBridge: this requires two addresses.
>>> 
>> 
>> It can certainly do so with the current header. It merely has to map
>> the source MAC address to the source RBridge -- something it would
>> end up doing for the reverse packet anyway.
> 
> The source MAC address is much easier to spoof than the
> ingress RBridge address, there is no guarantee that the frame
> entered the RBridge cloud at the RBridge derived by the mapping you
> propose. 
> 
>> 
> The issue is not Rogue RBridges, the issue is that in a
> network there will be RBridges that will connect unsecured
> hosts/links and the network manager may desire an easy way to
> restrict them to a subset of the TRILL cloud.
> 
>> a larger shim header to optimize dropping their packets then things
>> are in a pretty bad shape. If there are network elements that cannot
>> ultimately be physically disconnected by the network administrator
>> then they should probably be separated by a router and not included
>> in the subnet.
> 
> In today world, any tool you can give a network administrator
> to segregate traffic is welcomed.
> 
>> 
>> And given that any RBRidge header is not going to have IPSEC quality
>> authentication the degree to which we can provide protection from a
>> malicious RBridge is fundamentally limited.
>> 
>> The originally proposed short envelope solves the essential problems.
>> The additional fields that Radia's recent draft suggested are all
>> interesting. Many of them MIGHT help RBridges perform certain
>> functions more efficiently. But I do not believe any of the extra
>> fields are necessary, and my initial thought is that they do not
>> justify eating away at the MTU.
> 
> I am much more concerned that TRILL will provide a superset
> of the functionalities that 802.1D and all its variations
> provide, than saving few bytes in the shim headers. I think
> the times where optimizing to the last byte was important are long
> gone with 1 and 10 GE. 
> 

No matter what the wire speed:

MsgSize/(n-4) >= MsgSize/n

And as we all know the probability of MsgSize having been
crafted so the MsgSize % n is zero is all too high. So the
more we add to the header, the more IP datagrams will be
required to send the same traffic. That's not only more
bandwidth, but a reduced probability of the entire message
arriving on first try, deeper queues in all the forwarding
elements, etc.

Using the larger header needs a solid justification, not 
just a presumption that bandwidth is cheap.

I am assuming there is no desire to replicate IPSEC funcationality
at L2 then *all* of the L2 headers may be forged. I don't see how
you can claim that any specific one is more trustworthy than
the others.