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

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

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Friday, October 13, 2006 9:43 AM
> To: Silvano Gai; Caitlin Bestler; Joe Touch
> Cc: rbridge at postel.org; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 
> --- [SNIP] ---
> -->
> --> 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.
> 
> Do you have a real deployment example in which an enterprise
> would not use firewalls and/or routers to protect an entire
> LAN but would use bridges to protect portions of it?

Enterprise uses any possible combination of Firewall, Routers, ACL at
the 5-tuple layers, VLANs, ACL at the MAC address layer and whatever
else you give them to protect their network. I have seen many large
networks and even if there are similarities, nobody does it exactly the
same way. 

Ingress / Egress RBridge address filtering is just a tool, as many
others to empower some network managers. Will it solve all the security
problems? NO.
Will it be used in several deployments? YES.

Of course, if we design the encapsulation so that it is not supported,
it cannot be done! Why do you want to preclude it?

Moreover when you have the ingress Rbridge address you can start to do
other things, as was observed in other emails, like policy forwarding.

-- Silvano

> 
> This does not sound very practical to me.
> 
> In addition - if you don't filter at an ingress, and it is
> possible to spoof the inner source MAC address - how is it
> useful to filter based on the ingress and egress RBridge at
> any point other than the ingress?  If you do, you are only
> saying that any traffic arriving from bridged segment "X"
> is not allowed to be delivered to bridged segment "Y" and -
> if that is what you want to do, there are better ways to do
> it than to use ACLs on a bridge (or RBridge).
> 
> -->
> --> > 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.
> 
> I'd like to hear that directly from a network administrator.  There
> are practical limits to the capacity of their "tool belt" and more
> tools means even more administration/management complexity.
> 
> -->
> --> >
> --> > 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 request was "let's be realistic."  The statement that "there
> may not be an IP layer" is a significant departure from realism,
> in today's networks.
> 
> -->
> -->
> --> > 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.
> 
> Herein lies the disconnect.  Attempting to support every variation
> of 802.1D in specifications produced by this WG is a non-starter.
> 
> We therefore have to decide what is, and is not, in scope.
> 
> Since there are certainly existance proofs of tunneling technologies
> that do not retain all of the information of the tunneled data in an
> "outer" (tunneling) encapsulation (indeed, what would be the point
> of tunneling otherwise), then it is completely legitimate to state
> that this is out of scope.
> 
> -->
> --> -- Silvano
> -->
> -->
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> rbridge at postel.org
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 15 Oct 2006 23:13:56 -0700

> it cannot be done! Why do you want to preclude it?

I don't think we're precluding ingress/egress filtering on the LAN, just
that it isn't needed inside the rbridge campus. Traffic either
originates inside the LAN (on an rbridge node or host) or enters via a
transit (a router). Both can be constrained with the outer ethernet
header addresses; there's nothing magic about the ingress or egress
rbridge node as far as filtering is concerned.

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/20061015/5a6e75ce/signature.bin

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 16 Oct 2006 09:02:49 -0700

Joe Touch wrote:

> 
> I don't think we're precluding ingress/egress filtering on
> the LAN, just that it isn't needed inside the rbridge campus.
> Traffic either originates inside the LAN (on an rbridge node
> or host) or enters via a transit (a router). Both can be
> constrained with the outer ethernet header addresses; there's
> nothing magic about the ingress or egress rbridge node as far as
> filtering is concerned. 
> 

Agreed.

More precisely, there WILL be environments with sufficient
perimeter ingress control that internal checking would not
be required. But if we put the extra fields in the header
they will ALWAYS be there.

Most of the extra fields CAN be derived from other information.
For example the enclosed source MAC address implies the 
source RBridge. Therefore it is hard to make a case that
they will provide a permanent benefit.

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 16 Oct 2006 09:49:28 -0700

> they will ALWAYS be there.

Rbridge traffic is already differentiated on a per-hop basis; what's the
utility in knowing the ingress? That increases - rather than decreases -
the state at the interior rbridge nodes.

> they will provide a permanent benefit. 

The enclosed source MAC indicates the source rbridge at the time it was
encapsulated; the appropriate source rbridge for that packet may change
by the time the packet arrives elsewhere in the rbridge campus. That's
another reason it's not useful to know the source - it is ephemeral anyway.

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