[rbridge] Updated charter

[pekkas at netcore.fi (Pekka Savola)]

Hi,

On Fri, 28 Jan 2005, marcelo bagnulo braun wrote:
> the charter is silent w.r.t security and during the BoF there were many 
> concerns about this (some of them, like Gab's comments, made a lot of sense 
> to me). Shouldn't the draft explicitly state that a threat analysis need to 
> be delivered and that no vulnerabilities can be introduced? (perhaps this is 
> obvious and there is no need to mention it, but anyway...)

Well, there are _always_ new vulnerabilities.

Maybe it is worth saying that the security must not get worse than it 
is currently with LANs (or heavily bridged LANs), or the like (a la 
multi6)?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
From touch at ISI.EDU  Fri Jan 28 08:58:24 2005
From: touch at ISI.EDU (Joe Touch)
Date: Fri Jan 28 09:01:59 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>
	<[e-mail]>	<[e-mail]>
	<[e-mail]>	<[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>



Radia Perlman wrote:
> Joe...I think you might have misunderstood what Erik wrote.

Hard to believe, since most of the ideas below are what I expected. 
Although I'm thinking more about correctness and the bounds of what ARP 
dests are allowed to do, rather than the 'typical' case.

> But at any 
> rate, I think
> some variant of the below are possibilities:

Some have problems:

> a) always flood ARP/ND query on the spanning tree

Works (clearly).

> b) always do an optimized reply (either proxy the reply or route the
> query to the RBridge that claims the
> destination is attached). Then if the first RBridge notices the 
> optimized thing
> didn't work (either because there is a retransmitted query within a 
> short amount of
> time or because there is no reply from the destination), then flood the 
> query.

If you proxy the reply and the destination has moved, then you're 
polluting the client's ARP cache.

If you don't, you're necessarily waiting for the second query, which 
means a delay.

> c) always route the query. (and if the destination has moved, eventually 
> the
> destination RBridge will notice and remove it from its LSP)

The 'eventually' again is the issue. And how does the dest rbridge know 
things have moved? And some clients may choose to respond to some ARPs 
and not others; in that case, silence on ARPs - which is _valid_ - 
causes the rbridge routing to thrash.

> d) always proxy the reply (and again, the destination RBridge will 
> eventually
> notice the destination has moved)

The destination rbridge wouldn't necessarily notice anything. You told 
the source where the dest is; packets flow, and are sent to the (now 
gone) dest. If this is UDP, nobody notices anything.

> e) have some timer where if there has been an ARP/ND reply from the 
> destination
> within some amount of time, then do the optimized thing (proxy or route 
> the query)

If I understand this one, it's a "positive reinforcement" version, i.e., 
routes only if valid ARPs have been seen in response. This sounds safer, 
but still has the 'timeout' problem.

> It's all a matter of what to optimize...overhead of discovery vs 
> bandwidth vs simplicity
> of protocol.

My concern is trading optimization for correctness. And the fact that 
we're optimizing for a protocol that caches anyway. Why?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050128/5967822f/signature.bin
From erik.nordmark at sun.com  Fri Jan 28 10:14:30 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Jan 28 10:16:51 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Joe Touch wrote:

>> We do need to handle movement, but I think it is desirable to not 
>> flood *every* ARP packet across the topology. So perhaps sending the 
>> first ARP packet using the MAC-address routing tables, but detecting a 
>> retransmitted ARP and flooding that one would be a reasonable compromise.
> 
> 
> How would you know when to stop flooding ARPs, e.g., when the node moves 
> on the other end?

The idea is that the rbridge can have a history of recent ARP packets 
(capturing a few seconds worth).
When it sees an ARP it does:
  - Is there an LSA for the mac address?
    - If not, flood (handle the case when the LSAs haven't been flooded yet)
    - If yes, is the sender and target in the recent history?
	Yes implies it could be a retransmitted ARP, so flood it
	No, no need to flood

   Erik

> In particular, what happens when its the second broadcast ARP that would 
> have worked?
> 
> Joe
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge