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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 12 Oct 2006 08:05:10 -0700

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.

IMHO addresses come in pair, I am not aware of a successful protocol
that has a single address.

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Thursday, October 12, 2006 7:30 AM
To: Silvano Gai
Cc: Radia Perlman; rbridge at postel.org
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> OK,
> Let's restrict the discussion to IEEE 802.1-compliant Ethernet
networks.
> 
> Today the outer header contains: 
> 
>    o  L2 destination = next RBridge, or for flooded frames, a new (to
be
> 
>       assigned) multicast layer 2 address meaning "all RBridges" 
> 
>    o  L2 source = transmitting RBridge (the one that most recently 
>       handled this frame)
> 
> If we want to avoid carrying the egress RBridge address in the shim
> header, we need to put it in the outer header - L2 destination.

The reason for the single shim rbridge address is a tradeoff, to avoid
populating the inner rbridge nodes with complete ingress tables. That's
a trade-off rather than a requirement.

If we went with strict minimalism, we could avoid the need for that
field; I understand the desire to avoid populating every node with full
tables, though. So I'll update my earlier note and add the single
desination/mulitcast source address field, as per the protocol doc.

As we go beyond that minimal requirement, we're starting to add
capability that looks more like IP than ethernet. IMO, rbridges should
support what ethernet supports, not necessarily what IP is capable of.
If you want IP, use IP.

Joe

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Thursday, October 12, 2006 7:07 AM
> To: Silvano Gai
> Cc: Radia Perlman; rbridge at postel.org
> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
>> Joe,
>>
>> Let me focus on the need of RBridge addresses.
>>
>> I didn't propose them; they are in the current WG draft:
>>
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
>> .txt
>> to achieve scalability at the ISIS level.
>>
>> The outer MAC addresses are present only if the frame is sent over
802
>> link (section 2.9), but it may not be present on other media;
> therefore
>> TRILL cannot rely on them.
>>
>> If you disagree with these two points, I think you disagree with the
>> work that has been done in TRILL till now.
> 
> I agree with the charter, which limits us to specifying solutions that
> work on 802.1 nets:
> 
> ---
> The TRILL WG will design a solution for shortest-path frame routing in
> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
> topologies, using an existing link-state routing protocol technology.
> ---
> 
> The fact that the architecture discusses other links is OK; it's
> informational anyway.
> 
> Joe
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 12 Oct 2006 08:54:44 -0700

Silvano Gai wrote:
> security hole.

That's trivial to spoof, so it's not a security issue per se. If there
is any filtering based on an address, it ought to be at the inner
address (which is already paired) anyway. If this is just for ACLs, it
seems like a thin reason.

> An Rbridge needs to be able to drop traffic originated by

-------------- 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/e12a0f24/signature.bin

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 12 Oct 2006 09:18:23 -0700

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.

If the frequency of rogue RBridges is high enough to justify
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.

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