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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 13 Oct 2006 13:32:44 -0700

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Friday, October 13, 2006 9:08 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?
> 
> 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.

I never proposed that.

> On the other hand, if you're talking about filtering based
> on the _ingress_ and _egress_ RBridges, there's no reasonable
> application for this.
> 

IMHO, there is.

-- Silvano

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