[rbridge] I got some answers from the IS-IS mailing list

[Eastlake III Donald-LDE008]

Anoop,

It just isn't the case that all Rbridges will be in networks that
strictly follow a division into edge and core Rbridges. Rbridges are
well suited to much more general meshes. So it takes a lot more than you
think to secure things. Although IS-IS messages can be secured by
existing IS-Is features, what's to stop some station, possibly on a
multi-access link, from injecting a TRILL data frame to pollute the
database of the egress Rbridge when it is decapsulated? There are other,
more complex scenarios.

You should also keep in mind that some people just plain would prefer to
learn via IS-IS messages than via decapsulated data, regardless of
security issues. It's partly a layer 3 versus layer 2 point of view
conflict.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 3:17 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list


Radia,

I don't see what this has to do with security.
If "secure enrolment" is a requirement, then
the edge rBridge won't transmit any frames
from an end node until it has completed secure
enrolment.  It won't learn the address, and 
nor will the egress rbridge.

I still don't get what the per-VLAN IS-IS 
instance would buy us.

Anoop

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Wednesday, June 20, 2007 12:14 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> What I am referring to as "per-VLAN instance of IS-IS" consists of 
> announcing attached
> endnodes and includes only attached endnodes in a particular VLAN.
> 
> It's optional to announce, and it's optional to learn from it.
> 
> I think it would be valuable for R1 to use to proactively announce 
> endnodes that have
> explicitly enrolled with R1 through a procedure more secure 
> than simply 
> sending a data
> packet with a (claimed) source address.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > Radia,
> >
> > Using learning at the edge Rbridges definitely
> > addresses the scaling issue for unicast.
> >
> > From your note below it's not clear if we're
> > still going to have per-VLAN instances of
> > IS-IS.  If we do, I still think we would 
> > have problems with it.
> >
> > One can always make an argument that a 
> > 802.1Q bridge doesn't realistically need
> > to support 2K or 4K or whatever number 
> > of VLANs.  However, they do support it, 
> > and there are customers out there that 
> > configure that many VLANs.
> >
> > If TRILL is even moderately successful,
> > we will likely encounter networks where
> > an rBridge needs to participate in 1000s
> > of VLANs.
> >
> > Anoop
> >
> >   
> >> -----Original Message-----
> >> From: rbridge-bounces at postel.org 
> >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> >> Sent: Friday, June 15, 2007 9:12 PM
> >> To: rbridge at postel.org
> >> Subject: [rbridge] I got some answers from the IS-IS mailing list
> >>
> >> 1) They have deployed a variant of IS-IS, and the way they 
> >> distinguish their instances is based on having a new 
> >> multicast address. I wrongly remembered IS-IS, and thought 
> >> that PSNPs got unicast, but even those are multicast (and I 
> >> remember the reasoning at the time this was decided 100 years 
> >> ago, which was to suppress lots of routers sending the same 
> >> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> >> from layer 3 IS-IS by having a different multicast address. 
> >> The bit in the header works too, however.
> >>
> >> 2) I checked to make sure that "0" would be OK to use as an 
> >> area address, and it is.
> >>
> >> 3) The solution I proposed to the scalability issue of having 
> >> a zillion pseudonodes on a LAN (having the DR give the same 
> >> name to all the pseudonodes that get spawned by running the 
> >> Hello protocol on a link according to each VLAN the DR 
> >> supports) works. 
> >> I was worried
> >> about nontransitive connectivity (R1, the DR, names the 
> >> pseudonode R1.1, and issues an LSP on behalf of the 
> >> pseudonode claiming to be attached to all the RBridges on the 
> >> link that can talk to R1 via any of the VLAN tags. But even 
> >> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> >> to R1 (using VLAN Tab B) does not mean that
> >> R2 and R3
> >> can talk to each other.)
> >>
> >> Interestingly, way back when IS-IS was DECnet phase V, and we 
> >> were worried about weird hardware problems creating 
> >> nontransitive connectivity, we put in what R2 should do when 
> >> the link state database implies R2 can talk to R3 through the 
> >> pseudonode, but
> >> R2 can't really talk to R3 -- R2 sends to the DR).
> >>
> >> So we can use this solution. So does that (and learning from 
> >> data packets rather than announcing all endnodes in per-VLAN 
> >> instances of IS-IS) answer everyone's scalability concerns?
> >>
> >> Radia
> >> _______________________________________________
> >> rbridge mailing list
> >> rbridge at postel.org
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>     
> 

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge