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

[Gray, Eric]

Silvano,

	You (re)make Joe's point, I believe.  It _is_ easy to
spoof a MAC address.   So it gains us nothing to attempt to
incorporate a source-MAC mapping in the outer encapsulation.
On the other hand, if you're talking about filtering based
on the _ingress_ and _egress_ RBridges, there's no reasonable
application for this.

	If you cannot trust the ingress and egress RBridges in
your own administrative domain, then you should expect them 
to be able to overcome this "filtering" through spoofing (as
Joe said already).

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> Sent: Thursday, October 12, 2006 12:14 PM
--> To: Joe Touch
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> 
--> -----Original Message-----
--> From: Joe Touch [mailto:touch at ISI.EDU] 
--> Sent: Thursday, October 12, 2006 8:55 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:
--> > 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.
--> 
--> That's trivial to spoof, 
--> 
--> Is it?  You need to emulate an RBridge to be able to spoof 
--> the RBridge
--> address. This includes passing all the link negotiation, bringing up
--> ISIS, passing the security test of ISIS. I will say it is 
--> much harder
--> that spoofing a MAC address or an IP address.
--> 
--> Agreed?
--> 
--> -- Silvano
--> 
--> 
--> 
--> 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
--> > 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
--> >>
--> > 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->