[rbridge] Updated charter

[touch at ISI.EDU (Joe Touch)]

Erik Nordmark wrote:
> Bill Sommerfeld wrote:
> 
>> Also: it would be very desirable if the behavior seen by hosts in the 
>> presence
>> of other misconfigured hosts should be the same or better than what 
>> you get
>> with a traditional network.
>>
>> As a specific example, when two or more nodes assert ownership over 
>> the same
>> address with arp, all nodes should see all the traffic (since hosts 
>> can ring
>> alarm bells/log/audit/etc. when they're being spoofed).
> 
> 
> I think you are stating a potential goal for rbridges that when multiple 
> hosts claim the same MAC address, they should all receive a copy of 
> packets to such a MAC address.
> Do folks agree that this would be reasonable?

I'm not sure that an rbridge should behave differently from a bridged 
system (below) in this regard.

> I don't think a solution can guarantee this when there is a mixture of 
> 802.1D bridges and rbridges, because 802.1D bridges don't provide this, 
> but as long as the hosts are attached to different rbridges I think it 
> would be possible.
-------------- 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/20050131/100a898d/signature.bin
From michsmit at cisco.com  Mon Jan 31 11:20:52 2005
From: michsmit at cisco.com (Michael Smith)
Date: Mon Jan 31 11:22:36 2005
Subject: [rbridge] Updated charter
In-Reply-To: <1107191286.1705.122.camel@thunk>
Message-ID: <[e-mail]>

 
> From: Bill Sommerfeld [mailto:[e-mail]] 
> Sent: Monday, January 31, 2005 9:08 AM
> Subject: RE: [rbridge] Updated charter
> 
> On Mon, 2005-01-31 at 11:56, Michael Smith wrote:
> >  
> > > What should it do when it can't tell?   If you allow for mobility 
> > > and unmanaged operation, you're going to have to allow 
> for addresses 
> > > to pop up at perhaps unexpected places, and *that* is what will 
> > > cause DoS potential.
> > 
> > Assuming the hosts are using DHCP, DHCP snooping at the 
> ingress bridge 
> > can be used to verify the MAC-to-IP binding ensuring that the DHCP 
> > policy is enforced.  If static addressing is used, then 
> there should 
> > probably be a static entry in the MAC-IP binding table.  That said, 
> > static addressing and mobility usually don't mix.
> 
> That didn't actually answer my question. 
> 
> I repeat: what should rbridges do when they can't tell 
> whether the MAC-IP binding is authorized?

Ok, to be more concise, IMHO, an out-of-the-box rbridge should do nothing
(today's behaviour).  The requestor will potentially receive multiple ARP
responses from the different hosts and can flag this behaviour if desired.  

I'm assuming by mirroring you are referring to replicating the ARP response
and unicasting it to each of the devices claiming the IP address.  To mirror
the ARP responses, the rbridges would potentially need to know all of the
MAC-IP bindings of all devices in the subnet.   This raises questions of how
long to remember the bindings, what happens when DHCP leases expire, etc.
Also, it's unclear which rbridge would do the mirroring as it would have to
be done in such a way that every rbridge in the path is not mirroring
(replicating) the packet and creating a giant DOS attack.

Michael

> 
> My suggestion regarding mirroring the arps is not intended to 
> replace enforcement when such mechanisms exist.
> 
> Instead, it is an attempt to get an out-of-the-box, unmanaged 
> rbridge net to behave at least as well as a broadcast 
> ethernet domain behaves -- the host being spoofed will 
> quickly become aware that spoofing is going on!
> 
> 						- Bill
> 

Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0VJKxQ27155 for <[e-mail]>; Mon, 31 Jan 2005 11:20:59 -0800 (PST)
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2005 11:22:02 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0VJKp1M004050; Mon, 31 Jan 2005 11:20:52 -0800 (PST)
Received: from michsmitw2k02 ([10.34.37.29]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBL97416; Mon, 31 Jan 2005 11:20:51 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Bill Sommerfeld'" <[e-mail]>
Subject: RE: [rbridge] Updated charter
Date: Mon, 31 Jan 2005 11:20:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <1107191286.1705.122.camel@thunk>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcUHt3rDTPF5x3EKSPeFmnI2nrhGeQADvO0Q
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2005 19:22:34 -0000
Status: RO
Content-Length: 2151

 
> From: Bill Sommerfeld [mailto:[e-mail]] 
> Sent: Monday, January 31, 2005 9:08 AM
> Subject: RE: [rbridge] Updated charter
> 
> On Mon, 2005-01-31 at 11:56, Michael Smith wrote:
> >  
> > > What should it do when it can't tell?   If you allow for mobility 
> > > and unmanaged operation, you're going to have to allow 
> for addresses 
> > > to pop up at perhaps unexpected places, and *that* is what will 
> > > cause DoS potential.
> > 
> > Assuming the hosts are using DHCP, DHCP snooping at the 
> ingress bridge 
> > can be used to verify the MAC-to-IP binding ensuring that the DHCP 
> > policy is enforced.  If static addressing is used, then 
> there should 
> > probably be a static entry in the MAC-IP binding table.  That said, 
> > static addressing and mobility usually don't mix.
> 
> That didn't actually answer my question. 
> 
> I repeat: what should rbridges do when they can't tell 
> whether the MAC-IP binding is authorized?

Ok, to be more concise, IMHO, an out-of-the-box rbridge should do nothing
(today's behaviour).  The requestor will potentially receive multiple ARP
responses from the different hosts and can flag this behaviour if desired.  

I'm assuming by mirroring you are referring to replicating the ARP response
and unicasting it to each of the devices claiming the IP address.  To mirror
the ARP responses, the rbridges would potentially need to know all of the
MAC-IP bindings of all devices in the subnet.   This raises questions of how
long to remember the bindings, what happens when DHCP leases expire, etc.
Also, it's unclear which rbridge would do the mirroring as it would have to
be done in such a way that every rbridge in the path is not mirroring
(replicating) the packet and creating a giant DOS attack.

Michael

> 
> My suggestion regarding mirroring the arps is not intended to 
> replace enforcement when such mechanisms exist.
> 
> Instead, it is an attempt to get an out-of-the-box, unmanaged 
> rbridge net to behave at least as well as a broadcast 
> ethernet domain behaves -- the host being spoofed will 
> quickly become aware that spoofing is going on!
> 
> 						- Bill
> 


Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0VIV4Q12817; Mon, 31 Jan 2005 10:31:04 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 31 Jan 2005 10:31:03 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<1106971684.2376.229.camel@thunk> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig304A8D840E124B432512C0C7"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2005 18:32:57 -0000
Status: RO
Content-Length: 1770

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig304A8D840E124B432512C0C7
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> Bill Sommerfeld wrote:
> 
>> Also: it would be very desirable if the behavior seen by hosts in the 
>> presence
>> of other misconfigured hosts should be the same or better than what 
>> you get
>> with a traditional network.
>>
>> As a specific example, when two or more nodes assert ownership over 
>> the same
>> address with arp, all nodes should see all the traffic (since hosts 
>> can ring
>> alarm bells/log/audit/etc. when they're being spoofed).
> 
> 
> I think you are stating a potential goal for rbridges that when multiple 
> hosts claim the same MAC address, they should all receive a copy of 
> packets to such a MAC address.
> Do folks agree that this would be reasonable?

I'm not sure that an rbridge should behave differently from a bridged 
system (below) in this regard.

> I don't think a solution can guarantee this when there is a mixture of 
> 802.1D bridges and rbridges, because 802.1D bridges don't provide this, 
> but as long as the hosts are attached to different rbridges I think it 
> would be possible.

--------------enig304A8D840E124B432512C0C7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/nlnE5f5cImnZrsRAj9YAKCQ5bvaEX/Qy81brDAZ2OIk5/BtdwCg5ifU
URTyiEyPQd8QMMupqa8lzcM=
=xMEF
-----END PGP SIGNATURE-----

--------------enig304A8D840E124B432512C0C7--


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0VH88Q17475 for <[e-mail]>; Mon, 31 Jan 2005 09:08:08 -0800 (PST)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0VH87Vu025934;  Mon, 31 Jan 2005 10:08:07 -0700 (MST)
Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0VH87Op016219; Mon, 31 Jan 2005 12:08:07 -0500 (EST)
Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j0VH87TC002501; Mon, 31 Jan 2005 12:08:07 -0500 (EST)
Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j0VH86YS002500; Mon, 31 Jan 2005 12:08:06 -0500 (EST)
X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to [e-mail] using -f
Subject: RE: [rbridge] Updated charter
From: Bill Sommerfeld <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <1107191286.1705.122.camel@thunk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.325 
Date: Mon, 31 Jan 2005 12:08:06 -0500
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2005 17:08:33 -0000
Status: RO
Content-Length: 1123

On Mon, 2005-01-31 at 11:56, Michael Smith wrote:
>  
> > What should it do when it can't tell?   If you allow for mobility 
> > and unmanaged operation, you're going to have to allow for 
> > addresses to pop up at perhaps unexpected places, and *that* 
> > is what will cause DoS potential.
> 
> Assuming the hosts are using DHCP, DHCP snooping at the ingress bridge can
> be used to verify the MAC-to-IP binding ensuring that the DHCP policy is
> enforced.  If static addressing is used, then there should probably be a
> static entry in the MAC-IP binding table.  That said, static addressing and
> mobility usually don't mix.

That didn't actually answer my question. 

I repeat: what should rbridges do when they can't tell whether the MAC-IP binding is
authorized?

My suggestion regarding mirroring the arps is not intended to replace enforcement 
when such mechanisms exist.

Instead, it is an attempt to get an out-of-the-box, unmanaged rbridge net to behave 
at least as well as a broadcast ethernet domain behaves -- the host being spoofed 
will quickly become aware that spoofing is going on!

						- Bill





Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0VGuSQ13686 for <[e-mail]>; Mon, 31 Jan 2005 08:56:28 -0800 (PST)
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2005 08:57:26 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0VGuK1M026325; Mon, 31 Jan 2005 08:56:20 -0800 (PST)
Received: from michsmitw2k02 (sjc-vpn6-462.cisco.com [10.21.121.206]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBL77892; Mon, 31 Jan 2005 08:56:19 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Bill Sommerfeld'" <[e-mail]>, "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Updated charter
Date: Mon, 31 Jan 2005 08:56:18 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcUGKXlkct157bVAR5CFew1M1yE36gBimeSA
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2005 16:58:35 -0000
Status: RO
Content-Length: 2104

 

> From: Bill Sommerfeld [mailto:[e-mail]] 
> Sent: Saturday, January 29, 2005 9:39 AM
> To: [e-mail]; Developing a hybrid router/bridge.
> 
> On Sat, 2005-01-29 at 12:07, Michael Smith wrote:
> 
> > Sending the ARP reponses to all hosts
> > claiming a particular IP address (in other words, 
> replicating the "bad"
> > traffic)
> 
> If the rbridge has a reliable way to tell a "good arp" from a 
> "bad arp", it should definitely not forward the "bad" ones.  
> 
> What should it do when it can't tell?   If you allow for mobility 
> and unmanaged operation, you're going to have to allow for 
> addresses to pop up at perhaps unexpected places, and *that* 
> is what will cause DoS potential.

Assuming the hosts are using DHCP, DHCP snooping at the ingress bridge can
be used to verify the MAC-to-IP binding ensuring that the DHCP policy is
enforced.  If static addressing is used, then there should probably be a
static entry in the MAC-IP binding table.  That said, static addressing and
mobility usually don't mix.
> 
> > IMHO, this
> > is functionality much better performed within the ingress rbridge 
> > rather than the egress host.
> 
> perhaps if all switches and hosts are under the same 
> administration and the network admins are good enough to tell 
> host admins that their switches detected this anomalous behavior....
> 
> but that presumes a state of organizational and operational 
> harmony between network and host administrators that i have 
> rarely encountered in the production networks I'm familiar with.

My understanding is that host addressing is usually in the domain of the
networking folks.  But in general, I agree, there are sometimes
organizational issues which in this case is probably between the network and
the security admins.  Typically, administrators have a much better idea of
the networking gear attached to their network than the hosts they have
attached. Relying on the rbridge to enforce MAC-IP binding seems much more
manageable than leaving it to the wide multitude of host devices on the
network.  

Michael

> 
> 						- Bill


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0THdFQ28559 for <[e-mail]>; Sat, 29 Jan 2005 09:39:15 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j0THdBpv020487;  Sat, 29 Jan 2005 09:39:11 -0800 (PST)
Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0THdAQp013935; Sat, 29 Jan 2005 12:39:10 -0500 (EST)
Subject: RE: [rbridge] Updated charter
From: Bill Sommerfeld <[e-mail]>
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.324 
Date: Sat, 29 Jan 2005 12:38:38 -0500
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 17:40:24 -0000
Status: RO
Content-Length: 1025

On Sat, 2005-01-29 at 12:07, Michael Smith wrote:

> Sending the ARP reponses to all hosts
> claiming a particular IP address (in other words, replicating the "bad"
> traffic) 

If the rbridge has a reliable way to tell a "good arp" from a "bad arp", it
should definitely not forward the "bad" ones.  

What should it do when it can't tell?   If you allow for mobility 
and unmanaged operation, you're going to have to allow for addresses to pop
up at perhaps unexpected places, and *that* is what will cause DoS potential.

> IMHO, this
> is functionality much better performed within the ingress rbridge rather
> than the egress host. 

perhaps if all switches and hosts are under the same administration and
the network admins are good enough to tell host admins that their switches detected this anomalous behavior....

but that presumes a state of organizational and operational harmony between
network and host administrators that i have rarely encountered in the
production networks I'm familiar with.

						- Bill




Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0TH7iQ21882 for <[e-mail]>; Sat, 29 Jan 2005 09:07:44 -0800 (PST)
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 29 Jan 2005 09:16:09 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-f.cisco.com (IDENT:[e-mail] [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0TH7Wl2008973 for <[e-mail]>; Sat, 29 Jan 2005 09:07:32 -0800 (PST)
Received: from michsmitw2k02 (sjc-vpn1-627.cisco.com [10.21.98.115]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BBL05541; Sat, 29 Jan 2005 09:07:35 -0800 (PST)
Message-Id: <[e-mail]>
From: "Michael Smith" <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Subject: RE: [rbridge] Updated charter
Date: Sat, 29 Jan 2005 09:07:35 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcUGEWBQg7Ksq3MASomAOWr0ulBqRgADw4Kg
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 17:08:29 -0000
Status: RO
Content-Length: 1838

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Bill Sommerfeld
> Sent: Saturday, January 29, 2005 6:41 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Updated charter
> 
> On Sat, 2005-01-29 at 05:08, marcelo bagnulo braun wrote:
> 
> > but, wouldn't this render trivial to sniff any communication across 
> > the whole bridged cloud?
> 
> Seems to me like the existing properties in the charter 
> (allow nodes to move at will; zero delay on new node 
> connection, etc) will already allow for relatively trivial 
> traffic hijacking, which, if anything, is worse than passive sniffing.
> 
> With both nodes getting the traffic you at least prevent that 
> denial-of-service.

Today, this is addressed in bridges using features such as 802.1X and
Cisco's Dynamic ARP Inspection.  Sending the ARP reponses to all hosts
claiming a particular IP address (in other words, replicating the "bad"
traffic) looks to open a wide possibility of DDoS attacks to both the hosts
involved and especially the rbridges performing the replication.  IMHO, this
is functionality much better performed within the ingress rbridge rather
than the egress host. 

Michael

> 
> > i mean, i don't think it would acceptable to substitute routers by 
> > rbridges if one of the costs is that anyone can sniff any 
> > communication....
> 
> I want it to be acceptable to replace bridges with rbridges; 
> I don't think it will be acceptable to do that if you can 
> spoof arp undetectably.
> 
> And nothing prevents the rbridge from locking down certain 
> addresses when local policy says to.
> 
> 							- Bill
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0TEfiQ21994 for <[e-mail]>; Sat, 29 Jan 2005 06:41:44 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0TEfhiI007535 for <[e-mail]>; Sat, 29 Jan 2005 06:41:43 -0800 (PST)
Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0TEfgQp019970; Sat, 29 Jan 2005 09:41:42 -0500 (EST)
Subject: Re: [rbridge] Updated charter
From: Bill Sommerfeld <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <1106971684.2376.229.camel@thunk> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ASCII
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.324 
Date: Sat, 29 Jan 2005 09:41:10 -0500
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 14:42:52 -0000
Status: RO
Content-Length: 894

On Sat, 2005-01-29 at 05:08, marcelo bagnulo braun wrote:

> but, wouldn't this render trivial to sniff any communication across the 
> whole bridged cloud?

Seems to me like the existing properties in the charter (allow nodes 
to move at will; zero delay on new node connection, etc) will already allow for
relatively trivial traffic hijacking, which, if anything, is worse than 
passive sniffing.

With both nodes getting the traffic you at least prevent that denial-of-service.

> i mean, i don't think it would acceptable to substitute routers by 
> rbridges if one of the costs is that anyone can sniff any 
> communication....

I want it to be acceptable to replace bridges with rbridges; I don't think it will
be acceptable to do that if you can spoof arp undetectably.

And nothing prevents the rbridge from locking down certain addresses when
local policy says to.

							- Bill







Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0TEPDQ18919 for <[e-mail]>; Sat, 29 Jan 2005 06:25:13 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0TEPCdt003998 for <[e-mail]>; Sat, 29 Jan 2005 07:25:13 -0700 (MST)
Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0TEPCQp018538; Sat, 29 Jan 2005 09:25:12 -0500 (EST)
Subject: Re: [rbridge] Updated charter
From: Bill Sommerfeld <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <1106971684.2376.229.camel@thunk>  <[e-mail]>
Content-Type: text/plain
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.324 
Date: Sat, 29 Jan 2005 09:24:40 -0500
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 14:26:51 -0000
Status: RO
Content-Length: 453

On Sat, 2005-01-29 at 00:15, Erik Nordmark wrote:

> I think you are stating a potential goal for rbridges that when multiple 
> hosts claim the same MAC address, they should all receive a copy of 
> packets to such a MAC address.

not quite; one way to accomplish what I was suggesting is to ensure that all nodes
see all ARP/ND traffic mentioning their IPv4/IPv6 address so that host based passive
duplicate address detection schemes can work.  







Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0TAAdQ00505 for <[e-mail]>; Sat, 29 Jan 2005 02:10:39 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 12A5B32BDE for <[e-mail]>; Sat, 29 Jan 2005 11:10:33 +0100 (CET)
Received: from [163.117.252.46] (unknown [163.117.252.46]) by smtp02.uc3m.es (Postfix) with ESMTP id D93E132BC5 for <[e-mail]>; Sat, 29 Jan 2005 11:10:31 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <1106971684.2376.229.camel@thunk> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
Subject: Re: [rbridge] Updated charter
Date: Sat, 29 Jan 2005 11:08:49 +0100
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j0TAAdQ00505
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 10:12:26 -0000
Status: RO
Content-Length: 1485

El 29/01/2005, a las 6:15, Erik Nordmark escribi?:

> Bill Sommerfeld wrote:
>
>> Also: it would be very desirable if the behavior seen by hosts in the 
>> presence
>> of other misconfigured hosts should be the same or better than what 
>> you get
>> with a traditional network.
>> As a specific example, when two or more nodes assert ownership over 
>> the same
>> address with arp, all nodes should see all the traffic (since hosts 
>> can ring
>> alarm bells/log/audit/etc. when they're being spoofed).
>
> I think you are stating a potential goal for rbridges that when 
> multiple hosts claim the same MAC address, they should all receive a 
> copy of packets to such a MAC address.
> Do folks agree that this would be reasonable?
>

but, wouldn't this render trivial to sniff any communication across the 
whole bridged cloud?
i mean, i don't think it would acceptable to substitute routers by 
rbridges if one of the costs is that anyone can sniff any 
communication....

Perhaps we need to define link-layer CGA addresses to properly address 
this issue?

Regards, marcelo

> I don't think a solution can guarantee this when there is a mixture of 
> 802.1D bridges and rbridges, because 802.1D bridges don't provide 
> this, but as long as the hosts are attached to different rbridges I 
> think it would be possible.
>
>    Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0T5GWQ05379 for <[e-mail]>; Fri, 28 Jan 2005 21:16:32 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0T5GViI026082 for <[e-mail]>; Fri, 28 Jan 2005 21:16:31 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0T5GQDk465371; Fri, 28 Jan 2005 21:16:26 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2005 21:15:41 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <1106971684.2376.229.camel@thunk>
In-Reply-To: <1106971684.2376.229.camel@thunk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 05:18:22 -0000
Status: RO
Content-Length: 900

Bill Sommerfeld wrote:

> Also: it would be very desirable if the behavior seen by hosts in the presence
> of other misconfigured hosts should be the same or better than what you get
> with a traditional network.
> 
> As a specific example, when two or more nodes assert ownership over the same
> address with arp, all nodes should see all the traffic (since hosts can ring
> alarm bells/log/audit/etc. when they're being spoofed).

I think you are stating a potential goal for rbridges that when multiple 
hosts claim the same MAC address, they should all receive a copy of 
packets to such a MAC address.
Do folks agree that this would be reasonable?

I don't think a solution can guarantee this when there is a mixture of 
802.1D bridges and rbridges, because 802.1D bridges don't provide this, 
but as long as the hosts are attached to different rbridges I think it 
would be possible.

    Erik


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0T487Q23202 for <[e-mail]>; Fri, 28 Jan 2005 20:08:07 -0800 (PST)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0T486dt025962 for <[e-mail]>; Fri, 28 Jan 2005 21:08:06 -0700 (MST)
Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0T485Op003734; Fri, 28 Jan 2005 23:08:06 -0500 (EST)
Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j0T485Gn022786; Fri, 28 Jan 2005 23:08:05 -0500 (EST)
Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j0T485UY022785; Fri, 28 Jan 2005 23:08:05 -0500 (EST)
X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to [e-mail] using -f
Subject: Re: [rbridge] Updated charter
From: Bill Sommerfeld <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1106971684.2376.229.camel@thunk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.325 
Date: Fri, 28 Jan 2005 23:08:05 -0500
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 04:09:45 -0000
Status: RO
Content-Length: 638

On Fri, 2005-01-28 at 14:03, Erik Nordmark wrote:

> There might be non-security AS type things we should cover as well, such 
> as recommending that the size of the rbridge cloud be limited due to 
> broadcasts being flooded.

Also: it would be very desirable if the behavior seen by hosts in the presence
of other misconfigured hosts should be the same or better than what you get
with a traditional network.

As a specific example, when two or more nodes assert ownership over the same
address with arp, all nodes should see all the traffic (since hosts can ring
alarm bells/log/audit/etc. when they're being spoofed).

							- Bill



Received: from ep_mailout3 (mailout3.samsung.com [203.254.224.33]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SNU8Q22436 for <[e-mail]>; Fri, 28 Jan 2005 15:30:08 -0800 (PST)
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <[e-mail]> for [e-mail]; Sat, 29 Jan 2005 08:30:02 +0900 (KST)
Received: from ep_mmp2 (ep_mailout3 [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 29 Jan 2005 08:30:01 +0900 (KST)
Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 29 Jan 2005 08:30:01 +0900 (KST)
Date: Fri, 28 Jan 2005 15:29:59 -0800
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] RBridges and SEND/CGA
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <00ef01c50591$49ccc300$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 23:30:24 -0000
Status: RO
Content-Length: 876

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

In IEEE 802.11, the L2 is connection-oriented. The L2 access device (AP,
Access Point) knows the MAC address of the newly associated host. So,
the new (serving) Rbridge in that case readily knows when a new host
connects.

Disconnect is not that "prompt". A host that walks away from the AP may
not properly tear-down the link. In that case, a timeout may be needed
(or, mechanisms like IAPP may help notifying the previous AP by the new
AP).

What happens in .11 is pretty common to wireless access technologies.
Not sure how applicable this is to wired networks. Does anyone know,
like in wired Ethernet served by a switch/bridge?

Anyways, we should be able to take advantage of this information where
available.

Alper




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SJ47Q12409 for <[e-mail]>; Fri, 28 Jan 2005 11:04:07 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0SJ47dt011249 for <[e-mail]>; Fri, 28 Jan 2005 12:04:07 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0SJ46gW281542; Fri, 28 Jan 2005 11:04:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2005 11:03:22 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 19:04:27 -0000
Status: RO
Content-Length: 862

marcelo bagnulo braun wrote:
> Hi Erik,
> 
> just one comment,
> 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...)

Good point. Perhaps the deliverable should be an applicability statement 
that points out things like filtering being harder than a routed network 
etc, so you don't want to think a rbridged network is a replacement for 
a routed network.

There might be non-security AS type things we should cover as well, such 
as recommending that the size of the rbridge cloud be limited due to 
broadcasts being flooded.

    Erik



Received: from [132.249.64.161] (client64-161.sdsc.edu [132.249.64.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SIpmQ08885; Fri, 28 Jan 2005 10:51:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2005 10:51:50 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBBFDE7CB2822746BB28D598A"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 18:52:23 -0000
Status: RO
Content-Length: 1875

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBBFDE7CB2822746BB28D598A
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> 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).

I.e.., and ARP cache ;-)

> 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

What's the benefit of that last case? How often is this going to happen 
that we need a special mechanism to deal with it?

Also, what does an LSA _mean_? How do you distinguish between an idle 
host and one that has moved but not sent traffic yet?

Joe

--------------enigBBFDE7CB2822746BB28D598A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+onGE5f5cImnZrsRAt6GAKCgCfkcjtyY3lQNCkYEey9vH1CUIwCcCSkj
PROywP0CUuGuxtaQFlbxhs4=
=1cH0
-----END PGP SIGNATURE-----

--------------enigBBFDE7CB2822746BB28D598A--


Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SIFGQ28582 for <[e-mail]>; Fri, 28 Jan 2005 10:15:16 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0SIFGiI023329 for <[e-mail]>; Fri, 28 Jan 2005 10:15:16 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0SIFFmE268353; Fri, 28 Jan 2005 10:15:15 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2005 10:14:30 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 18:16:50 -0000
Status: RO
Content-Length: 1147

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



Received: from [132.249.64.161] (client64-161.sdsc.edu [132.249.64.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SGwSQ05176; Fri, 28 Jan 2005 08:58:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2005 08:58:24 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24366EEBBA6C28E9764E7C44"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 17:01:58 -0000
Status: RO
Content-Length: 3036

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig24366EEBBA6C28E9764E7C44
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



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

--------------enig24366EEBBA6C28E9764E7C44
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+m82E5f5cImnZrsRAkiLAJ0S6NNhdebe0BatsItc3NVjhz3pqQCgy6Ab
Xw3F1OO3D14FRWnkS1ZewAM=
=/QvX
-----END PGP SIGNATURE-----

--------------enig24366EEBBA6C28E9764E7C44--


Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SAI1Q22201 for <[e-mail]>; Fri, 28 Jan 2005 02:18:01 -0800 (PST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0SAHsd13004 for <[e-mail]>; Fri, 28 Jan 2005 12:17:54 +0200
Date: Fri, 28 Jan 2005 12:17:54 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Updated charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 10:18:20 -0000
Status: RO
Content-Length: 816

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


Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0SA8bQ20392 for <[e-mail]>; Fri, 28 Jan 2005 02:08:38 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F33B645CDD for <[e-mail]>; Fri, 28 Jan 2005 11:08:30 +0100 (CET)
Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp01.uc3m.es (Postfix) with ESMTP id DDCDF45CB3 for <[e-mail]>; Fri, 28 Jan 2005 11:08:30 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
Subject: Re: [rbridge] Updated charter
Date: Fri, 28 Jan 2005 11:08:39 +0100
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j0SA8bQ20392
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 10:10:53 -0000
Status: RO
Content-Length: 4872

Hi Erik,

just one comment,
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...)

Regards, marcelo

El 28/01/2005, a las 2:50, Erik Nordmark escribi?:

>
> Based on the feedback from the BoF in August and some preliminary 
> feedback from IESG/IAB members, I've edited the charter.
>
> There are additions about supporting clouds which contain different L2 
> technologies (something folks asked about at the BoF, but we didn't 
> talk about) and we can have technical discussions about that on the 
> list.
>
> There is also some more flushing out of details.
>
> And editorial changes to make the description more positive.
>
> Hopefully this can be used to get a BoF and start the WG chartering 
> discussion.
>
>    Erik
>
>
> While IEEE 802 bridges are attractive due to not needing explicit
> configuration and allowing hosts to move within the bridged topology,
> they are more limited than IP routers since bridges
> only support IEEE 802 technologies, and the most common layer 2
> interconnection method (dynamically created spanning tree
> formation using bridges) is not as flexible and robust as layer 3 
> routing.
>
> The WG will design a hybrid solution that combines the simplicity of
> configuration while taking full advantage of complex topologies.
>
> The design should have the following properties:
>  - zero configuration of the hybrid devices
>  - ability for hosts to move without changing their IP address
>  - it should be possible to forward packets using pair-wise shortest 
> paths,
>    and exploit the redundant paths through the network for increased
>    aggregate bandwidth
>  - ARP and Neighbor Discovery packets should be optimized and not 
> necessarily
>    be flooded everywhere
>  - support Secure Neighbor Discovery
>  - the packet header should have a hop count for robustness in the 
> presence
>    of temporary routing loops
>  - nodes should be able to have multiple attachments to the network
>  - no delay when a new node is attached to the network
>  - multicast should work (and after a re-charter it might make sense to
>    look at optimizations for IP multicast)
>
> The working group will look into solutions that can interconnect 
> different
> layer 2 technologies, and also look at providing support for non-IP 
> protocols,
> even though one can not combine those two features together; the
> interconnection of different layer 2 technologies (with different 
> layer 2
> address formats) will most likely only work for the IP family of 
> protocols.
>
> The WG will design a protocol that combines the benefits of bridges
> and routers in a way that will co-exist with existing hosts, IP routers
> and bridges. The design should support both IPv4 and IPv6
>
> The working group will not work any layer 3 aspects except to provide
>  - Optimizations so that ARP and ND packets are not always
>    flooded everywhere
>  - Being able to carry IP multicast packets using flooding (which will
>    presumably fall out by being able to flood L2 multicast packets, so 
> there
>    might not be any specific work needed here).
>  - Defining the L3 operations needed to interconnect different L2 
> technologies
>
> The work consists of several, separable pieces:
>  - Defining what information should be carried in routing protocols in 
> order
>    to support this concept. The encoding of this information within the
>    routing protocol will be left as an action item for the specific 
> routing
>    protocol WG.
>  - Defining what information must be carried in an encapsulation 
> header for
>    data packets, and how to map that information to various link types 
> (e.g.,
>    IEEE LAN, Fibrechannel, MPLS)
>  - Defining how address resolution (ARP and Neighbor Discovery) is 
> performed,
>    taking into account the desire to be compatible with Secure Neighbor
>    Discovery.
>  - Defining how the solution extends to the case when multiple layer 2
>    technologies, that have different address format/length, are 
> interconnected.
>
> Deliverables
>  - A short draft on the problem statement and goals
>  - A document defining what information needs to be carried in routing
>    protocols to support the rbridge concept.
>  - Encapsulation draft specifying what needs to be carried in general
>    and the specific format to use on IEEE LANs
>  - ARP and ND draft
>  - Draft on interconnecting different types of layer 2 technologies
>
> ---
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S5erQ19757 for <[e-mail]>; Thu, 27 Jan 2005 21:40:54 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0S5erVu022697 for <[e-mail]>; Thu, 27 Jan 2005 22:40:53 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 28 Jan 2005 00:40:52 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-147-152-25.Central.Sun.COM [129.147.152.25]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 28 Jan 2005 00:40:52 -0500 (EST)
Date: Thu, 27 Jan 2005 21:40:53 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 05:42:23 -0000
Status: RO
Content-Length: 2133

Joe...I think you might have misunderstood what Erik wrote. But at any 
rate, I think
some variant of the below are possibilities:

a) always flood ARP/ND query on the spanning tree
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.
c) always route the query. (and if the destination has moved, eventually the
destination RBridge will notice and remove it from its LSP)
d) always proxy the reply (and again, the destination RBridge will 
eventually
notice the destination has moved)
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)

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

Radia



Joe Touch wrote:

>
>
> Erik Nordmark wrote:
>
>> Joe Touch wrote:
>>
>>>
>>> IMO, choosing not to flood a broadcast packet is a bad thing. In 
>>> this case, when the host moves, if the host is otherwise silent, 
>>> there's no way to find it until the ARP routing tables die out (if 
>>> they're separate, and if they ever do die out).
>>
>>
>>
>> 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?
>
> 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
>  
>


Received: from ms-smtp-02-eri0.socal.rr.com (ms-smtp-02-qfe0.socal.rr.com [66.75.162.134]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S51AQ10040 for <[e-mail]>; Thu, 27 Jan 2005 21:01:10 -0800 (PST)
Received: from [10.0.0.86] (rrcs-66-27-51-221.west.biz.rr.com [66.27.51.221]) by ms-smtp-02-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id j0S5146V025172; Thu, 27 Jan 2005 21:01:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 21:01:06 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8602CCF40929EA28D980445"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 05:02:24 -0000
Status: RO
Content-Length: 1498

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD8602CCF40929EA28D980445
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> Joe Touch wrote:
> 
>>
>> IMO, choosing not to flood a broadcast packet is a bad thing. In this 
>> case, when the host moves, if the host is otherwise silent, there's no 
>> way to find it until the ARP routing tables die out (if they're 
>> separate, and if they ever do die out).
> 
> 
> 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?

In particular, what happens when its the second broadcast ARP that would 
have worked?

Joe

--------------enigD8602CCF40929EA28D980445
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+ccSE5f5cImnZrsRAmn/AJ43fUC8qP14Whwa4rbS+rC5cbl2bQCfcvb3
J0EmJP78efJxajtY9ZD1ZfA=
=P8GE
-----END PGP SIGNATURE-----

--------------enigD8602CCF40929EA28D980445--


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S1ogQ25235 for <[e-mail]>; Thu, 27 Jan 2005 17:50:42 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.85.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0S1ofdt017334 for <[e-mail]>; Thu, 27 Jan 2005 18:50:41 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0S1ofgM911155; Thu, 27 Jan 2005 17:50:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 17:50:04 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: multipart/mixed; boundary="------------080801050205030601090804"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 01:52:37 -0000
Status: RO
Content-Length: 4467

This is a multi-part message in MIME format.
--------------080801050205030601090804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Based on the feedback from the BoF in August and some preliminary 
feedback from IESG/IAB members, I've edited the charter.

There are additions about supporting clouds which contain different L2 
technologies (something folks asked about at the BoF, but we didn't talk 
about) and we can have technical discussions about that on the list.

There is also some more flushing out of details.

And editorial changes to make the description more positive.

Hopefully this can be used to get a BoF and start the WG chartering 
discussion.

    Erik



--------------080801050205030601090804
Content-Type: text/plain;
 name="rbridge-charter"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rbridge-charter"

While IEEE 802 bridges are attractive due to not needing explicit 
configuration and allowing hosts to move within the bridged topology,
they are more limited than IP routers since bridges 
only support IEEE 802 technologies, and the most common layer 2 
interconnection method (dynamically created spanning tree 
formation using bridges) is not as flexible and robust as layer 3 routing. 

The WG will design a hybrid solution that combines the simplicity of 
configuration while taking full advantage of complex topologies.

The design should have the following properties:
 - zero configuration of the hybrid devices
 - ability for hosts to move without changing their IP address
 - it should be possible to forward packets using pair-wise shortest paths,
   and exploit the redundant paths through the network for increased
   aggregate bandwidth
 - ARP and Neighbor Discovery packets should be optimized and not necessarily
   be flooded everywhere
 - support Secure Neighbor Discovery
 - the packet header should have a hop count for robustness in the presence
   of temporary routing loops
 - nodes should be able to have multiple attachments to the network
 - no delay when a new node is attached to the network
 - multicast should work (and after a re-charter it might make sense to 
   look at optimizations for IP multicast)

The working group will look into solutions that can interconnect different
layer 2 technologies, and also look at providing support for non-IP protocols,
even though one can not combine those two features together; the 
interconnection of different layer 2 technologies (with different layer 2
address formats) will most likely only work for the IP family of protocols.

The WG will design a protocol that combines the benefits of bridges 
and routers in a way that will co-exist with existing hosts, IP routers
and bridges. The design should support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
 - Optimizations so that ARP and ND packets are not always
   flooded everywhere
 - Being able to carry IP multicast packets using flooding (which will
   presumably fall out by being able to flood L2 multicast packets, so there
   might not be any specific work needed here).
 - Defining the L3 operations needed to interconnect different L2 technologies

The work consists of several, separable pieces:
 - Defining what information should be carried in routing protocols in order
   to support this concept. The encoding of this information within the
   routing protocol will be left as an action item for the specific routing
   protocol WG. 
 - Defining what information must be carried in an encapsulation header for
   data packets, and how to map that information to various link types (e.g.,
   IEEE LAN, Fibrechannel, MPLS)
 - Defining how address resolution (ARP and Neighbor Discovery) is performed,
   taking into account the desire to be compatible with Secure Neighbor 
   Discovery.
 - Defining how the solution extends to the case when multiple layer 2
   technologies, that have different address format/length, are interconnected.

Deliverables
 - A short draft on the problem statement and goals
 - A document defining what information needs to be carried in routing
   protocols to support the rbridge concept.
 - Encapsulation draft specifying what needs to be carried in general
   and the specific format to use on IEEE LANs
 - ARP and ND draft
 - Draft on interconnecting different types of layer 2 technologies

---


--------------080801050205030601090804--


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S1OhQ18652 for <[e-mail]>; Thu, 27 Jan 2005 17:24:43 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0S1OgVu004790 for <[e-mail]>; Thu, 27 Jan 2005 18:24:42 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 27 Jan 2005 20:24:42 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-147-152-25.Central.Sun.COM [129.147.152.25]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 27 Jan 2005 20:24:42 -0500 (EST)
Date: Thu, 27 Jan 2005 17:24:43 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 01:26:36 -0000
Status: RO
Content-Length: 1732

Or perhaps in the case of routing the query, having the source's RBridge
noticing if there is a reply to the routed ARP/ND query, and if there is 
not, then
retrying with flooding.

For pure proxy (not routing the query), it might be nice if ARP/ND could 
have a flag
like DECnet did. DECnet had a flag called "tryhard" in the API to
layer 3, in which the upper layer could set it in order to tell layer 3 
to delete any
caches that might be incorrect. So if there were such a way to signal in 
the query
when communication is not working (because perhaps the MAC address in your
ARP cache is wrong), so that the RBridge should check the validity of 
the information
it is proxying...

It is unlikely this change would ever be put into ARP, and it makes 
RBridges less transparent.

But by the way, is there any way of doing the DECnet "tryhard" thing
within a node? (have the upper layer signal
that perhaps the local ARP cache is wrong and should be refreshed?)

Radia

Erik Nordmark wrote:

> Joe Touch wrote:
>
>>
>> IMO, choosing not to flood a broadcast packet is a bad thing. In this 
>> case, when the host moves, if the host is otherwise silent, there's 
>> no way to find it until the ARP routing tables die out (if they're 
>> separate, and if they ever do die out).
>
>
> 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.
>
>   Erik
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S0uIQ08321 for <[e-mail]>; Thu, 27 Jan 2005 16:56:18 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0S0u9iI023208 for <[e-mail]>; Thu, 27 Jan 2005 16:56:10 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0S0u9hI899594; Thu, 27 Jan 2005 16:56:09 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 16:55:33 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 00:58:24 -0000
Status: RO
Content-Length: 572

Joe Touch wrote:

> 
> IMO, choosing not to flood a broadcast packet is a bad thing. In this 
> case, when the host moves, if the host is otherwise silent, there's no 
> way to find it until the ARP routing tables die out (if they're 
> separate, and if they ever do die out).

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.

   Erik




Received: from [132.249.64.161] (client64-161.sdsc.edu [132.249.64.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S0jbQ05815; Thu, 27 Jan 2005 16:45:37 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 16:45:38 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF9F9523959E56E09C0EB7EC"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 00:47:11 -0000
Status: RO
Content-Length: 3387

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBF9F9523959E56E09C0EB7EC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Greg Daley wrote:
> Hi Joe,
> 
> Joe Touch wrote:
> 
>>
>>
>> Erik Nordmark wrote:
>>
>>> Radia Perlman wrote:
>>>
>> ...
>>
>>>> If so, perhaps ARP should be handled per Erik's suggestion...not 
>>>> actually
>>>> flooding the query, but still making the target actually answer the 
>>>> query (by having the
>>>> first RBridge forward the query to the destination RBridge).
>>>
>>>
>>>
>>> Even if we don't have the above concerns for ARP, it might still be 
>>> simpler to say that the rbridges make the delivery of the ARP more 
>>> efficient (no flooding when the bridges know where the target is) but 
>>> the rbridges never proxy respond to an ARP packet.
>>> That way we get less flooding of ARPs, yet keep the rbridges simple 
>>> and future proof for weird ARP stuff.
>>
>>
>>
>> IMO, choosing not to flood a broadcast packet is a bad thing. In this 
>> case, when the host moves, if the host is otherwise silent, there's no 
>> way to find it until the ARP routing tables die out (if they're 
>> separate, and if they ever do die out).
>>
>> I.e., "never proxy respond to an ARP packet" is good.
>> "Never ROUTE a broadcast packet" may also be necessary.
> 
> 
> If we're talking about moving nodes (MNs), with rbridges providing
> local proxy service, I guess there's two approaches:
> 
> 1) Probe across the routed fabric for updated locations for MNs
> 
>    perhaps this could be done with ND, but potentially
>    asynchronously.

Why? Why not allow ARP (we were talking about ARP, i.e., IPv4, at one 
point, and I still am) to use broadcast?

> In almost all locations in the rbridge the
>    service ND needs to be proxied, only on sublinks which the MN has
>    just moved to or from will this change.

Broadcast services need not be proxied; if you disagree, please prove 
otherwise.

And how does one magically find the sublink to which nodes move? (again, 
in IPv4?) - assume static IP config, so you can't assume DHCP helps you 
here.

> 2) ensure that the MN provides updated information upon arrival,
>    propagate this change to the other rbridges.
> 
>    The really tricky bit here is to find a hook into the protocols
>    which ensure that the MN updates the router with a unique identity
>    which is able to be tied to the last location.  I can't think of
>    a part of IPv6 which can be used this way off the top of my head
>    (unless the MAC address moves, and we can track that... it's
>    hardly secure though).
> 
> I'd guess it would be possible do #1 fairly readily though.
> 
> Greg Daley
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigBF9F9523959E56E09C0EB7EC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+YsyE5f5cImnZrsRApHzAKC4ZimT4P7HyncH5mIUiZdgFCguhQCgl4ZK
XG7sLoJQsRHTr778RCP+6as=
=vBQk
-----END PGP SIGNATURE-----

--------------enigBF9F9523959E56E09C0EB7EC--


Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S0V1Q01548 for <[e-mail]>; Thu, 27 Jan 2005 16:31:01 -0800 (PST)
Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <[e-mail]> for [e-mail]; Fri, 28 Jan 2005 11:30:42 +1100
Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 13FE280004	for <[e-mail]>; Fri, 28 Jan 2005 11:30:42 +1100 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id CF7043C016	for <[e-mail]>; Fri, 28 Jan 2005 11:30:41 +1100 (EST)
Date: Fri, 28 Jan 2005 11:30:40 +1100
From: Greg Daley <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
X-Accept-Language: en, en-us
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 00:32:23 -0000
Status: RO
Content-Length: 2088

Hi Joe,

Joe Touch wrote:
> 
> 
> Erik Nordmark wrote:
> 
>> Radia Perlman wrote:
>>
> ...
> 
>>> If so, perhaps ARP should be handled per Erik's suggestion...not 
>>> actually
>>> flooding the query, but still making the target actually answer the 
>>> query (by having the
>>> first RBridge forward the query to the destination RBridge).
>>
>>
>> Even if we don't have the above concerns for ARP, it might still be 
>> simpler to say that the rbridges make the delivery of the ARP more 
>> efficient (no flooding when the bridges know where the target is) but 
>> the rbridges never proxy respond to an ARP packet.
>> That way we get less flooding of ARPs, yet keep the rbridges simple 
>> and future proof for weird ARP stuff.
> 
> 
> IMO, choosing not to flood a broadcast packet is a bad thing. In this 
> case, when the host moves, if the host is otherwise silent, there's no 
> way to find it until the ARP routing tables die out (if they're 
> separate, and if they ever do die out).
> 
> I.e., "never proxy respond to an ARP packet" is good.
> "Never ROUTE a broadcast packet" may also be necessary.

If we're talking about moving nodes (MNs), with rbridges providing
local proxy service, I guess there's two approaches:

1) Probe across the routed fabric for updated locations for MNs

    perhaps this could be done with ND, but potentially
    asynchronously.  In almost all locations in the rbridge the
    service ND needs to be proxied, only on sublinks which the MN has
    just moved to or from will this change.

2) ensure that the MN provides updated information upon arrival,
    propagate this change to the other rbridges.

    The really tricky bit here is to find a hook into the protocols
    which ensure that the MN updates the router with a unique identity
    which is able to be tied to the last location.  I can't think of
    a part of IPv6 which can be used this way off the top of my head
    (unless the MAC address moves, and we can track that... it's
    hardly secure though).

I'd guess it would be possible do #1 fairly readily though.

Greg Daley


Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0S0JPQ28176 for <[e-mail]>; Thu, 27 Jan 2005 16:19:25 -0800 (PST)
Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <[e-mail]> for [e-mail]; Fri, 28 Jan 2005 11:19:17 +1100
Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3D1C80002	for <[e-mail]>; Fri, 28 Jan 2005 11:19:17 +1100 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9623C3C006	for <[e-mail]>; Fri, 28 Jan 2005 11:19:17 +1100 (EST)
Date: Fri, 28 Jan 2005 11:19:17 +1100
From: Greg Daley <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 00:20:50 -0000
Status: RO
Content-Length: 1170

Hi Donald,

Sorry about the tardy reply,

Eastlake III Donald-LDE008 wrote:
> One advantage of RBridges is that, with IP optimizations, they can do proxy ARP greatly reducing ARP flooding. I was thinking about whether this also applies to signed Neighbor Discovery messages in IPv6. Seems to me that it does.
> 
> In particular, if you pass along in the link state message not only MAC addresses but also the corresponding IP addresses and ND signatures, then the RBridges can do proxy ND and greatly reduce ND flooding the same way they can reduce ARP flooding. So it seems very simple to do.
> 
> Has anyone else thought about this?

proxy arp is not trivial in SEND, due to the origin devices signing
information regarding their link-layer address in the ND messages.

This is incompatible with any proposals where intervening devices
need to substitute their own MAC address as the next destination
for a packet.

A short draft describing some of the issues is available at:

http://www.ietf.org/internet-drafts/draft-daley-send-spnd-prob-00.txt

This is mainly aimed at Mobile-IPv6, since there's not been much
interest in SEND and proxy ND otherwise.

Greg Daley.


Received: from [132.249.64.161] (client64-161.sdsc.edu [132.249.64.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0RNCpQ10054; Thu, 27 Jan 2005 15:12:51 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 15:12:52 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7BF5F7D401DB1B1F363A4700"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 23:14:47 -0000
Status: RO
Content-Length: 1743

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7BF5F7D401DB1B1F363A4700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:
> Radia Perlman wrote:
> 
...
>> If so, perhaps ARP should be handled per Erik's suggestion...not actually
>> flooding the query, but still making the target actually answer the 
>> query (by having the
>> first RBridge forward the query to the destination RBridge).
> 
> Even if we don't have the above concerns for ARP, it might still be 
> simpler to say that the rbridges make the delivery of the ARP more 
> efficient (no flooding when the bridges know where the target is) but 
> the rbridges never proxy respond to an ARP packet.
> That way we get less flooding of ARPs, yet keep the rbridges simple and 
> future proof for weird ARP stuff.

IMO, choosing not to flood a broadcast packet is a bad thing. In this 
case, when the host moves, if the host is otherwise silent, there's no 
way to find it until the ARP routing tables die out (if they're 
separate, and if they ever do die out).

I.e., "never proxy respond to an ARP packet" is good.
"Never ROUTE a broadcast packet" may also be necessary.

Joe

--------------enig7BF5F7D401DB1B1F363A4700
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFB+XV0E5f5cImnZrsRAh9dAJixopuONbrosQI/cz8TS7yGadJZAKCdJ2ki
OOfjmoHmWLfa9M6F+ZU4Sg==
=NCd3
-----END PGP SIGNATURE-----

--------------enig7BF5F7D401DB1B1F363A4700--


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0RLlxQ14398 for <[e-mail]>; Thu, 27 Jan 2005 13:47:59 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j0RLlxpv022627 for <[e-mail]>; Thu, 27 Jan 2005 13:47:59 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0RLlw0M844334; Thu, 27 Jan 2005 13:47:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 13:47:22 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 21:48:21 -0000
Status: RO
Content-Length: 1448

Radia Perlman wrote:

> I was wondering why they would want replay protection. In the case where
> the target has changed its layer 2 address, you wouldn't want someone 
> replaying the
> old ND reply. Is there any other case for which SEND would want 
> freshness, as in perhaps
> a form of low-level ping to see if the node is actually alive? Would 
> anyone use ARP
> this way? 

I don't know if this is done or not(but using ARP broadcast as a 
liveness test would be more expensive than using unicast ICMP echo, so 
hopefully this isn't that common).

The other thing one could be concerned about is if there are some 
non-standard extensions to arp (extra stuff at the end?) which needs to 
be carried between the hosts. I've never heard of such a thing for ARP 
over Ethernet, so I don't know if one needs to worry about this.

> If so, perhaps ARP should be handled per Erik's 
> suggestion...not actually
> flooding the query, but still making the target actually answer the 
> query (by having the
> first RBridge forward the query to the destination RBridge).

Even if we don't have the above concerns for ARP, it might still be 
simpler to say that the rbridges make the delivery of the ARP more 
efficient (no flooding when the bridges know where the target is) but 
the rbridges never proxy respond to an ARP packet.
That way we get less flooding of ARPs, yet keep the rbridges simple and 
future proof for weird ARP stuff.

    Erik


Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0R59kQ12184 for <[e-mail]>; Wed, 26 Jan 2005 21:09:48 -0800 (PST)
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j0R50OWG001836 for <[e-mail]>; Wed, 26 Jan 2005 22:00:24 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j0R59tO8011759 for <[e-mail]>; Wed, 26 Jan 2005 23:09:56 -0600 (CST)
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <ZH8SS7D7>; Thu, 27 Jan 2005 00:09:43 -0500
Message-ID: <[e-mail]>
From: Eastlake III Donald-LDE008 <[e-mail]>
To: [e-mail]
Subject: RE: [rbridge] RBridges and SEND/CGA
Date: Thu, 27 Jan 2005 00:09:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 05:10:16 -0000
Status: RO
Content-Length: 1650

Ahhh, you are correct. All the secured messages use a nonce or
Timestamp.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Erik Nordmark
Sent: Wednesday, January 26, 2005 6:09 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] RBridges and SEND/CGA

Eastlake III Donald-LDE008 wrote:
> One advantage of RBridges is that, with IP optimizations, they can do
> proxy ARP greatly reducing ARP flooding. I was thinking about whether
> this also applies to signed Neighbor Discovery messages in IPv6.
> Seems to me that it does.
> 
> In particular, if you pass along in the link state message not only
> MAC addresses but also the corresponding IP addresses and ND
> signatures, then the RBridges can do proxy ND and greatly reduce ND
> flooding the same way they can reduce ARP flooding. So it seems very
> simple to do.

SeND has replay protection for solicited information (NA as a result of 
a NS, RA as result of a RS) that uses nonces if I'm not mistaken.
Since the nonce is protected by the signature, the rbridge can't replay 
a NA/RA in response to a NS/RS, since it would be detected.
(I think the unsolicited information uses a time stamp instead, which 
allows for some amount of caching and replay by an rbride).

But the packets still don't need to be flooded across the whole topology 
since the first rbridge in the path can send the packet to the last 
rbridge in the path, so that the host can respond.

   Erik
_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0R0vGQ09170 for <[e-mail]>; Wed, 26 Jan 2005 16:57:16 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0R0vFdt012871 for <[e-mail]>; Wed, 26 Jan 2005 17:57:15 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 26 Jan 2005 19:57:15 -0500 (EST)
Received: from [192.168.2.58] (vpn-129-147-152-25.Central.Sun.COM [129.147.152.25]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 26 Jan 2005 19:57:15 -0500 (EST)
Date: Wed, 26 Jan 2005 16:57:16 -0800
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
References: <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 00:58:46 -0000
Status: RO
Content-Length: 2486

It wasn't easy finding the SEND draft. I can't find it listed under 
drafts in the IPv6 group. I found
it by doing a search under internet drafts. And I couldn't find a WG 
called SEND. But
anyway, for benefit of anyone else who wants to look at the SEND draft:

http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-06.txt

And indeed it does have timestamp and nonce options. But Erik's 
suggestion nicely
avoids flooding the ND query and reply even with nonces, and also avoids 
cluttering
the LSP info with signatures.

I was wondering why they would want replay protection. In the case where
the target has changed its layer 2 address, you wouldn't want someone 
replaying the
old ND reply. Is there any other case for which SEND would want 
freshness, as in perhaps
a form of low-level ping to see if the node is actually alive? Would 
anyone use ARP
this way? If so, perhaps ARP should be handled per Erik's 
suggestion...not actually
flooding the query, but still making the target actually answer the 
query (by having the
first RBridge forward the query to the destination RBridge).


Radia




Erik Nordmark wrote:

> Eastlake III Donald-LDE008 wrote:
>
>> One advantage of RBridges is that, with IP optimizations, they can do
>> proxy ARP greatly reducing ARP flooding. I was thinking about whether
>> this also applies to signed Neighbor Discovery messages in IPv6.
>> Seems to me that it does.
>>
>> In particular, if you pass along in the link state message not only
>> MAC addresses but also the corresponding IP addresses and ND
>> signatures, then the RBridges can do proxy ND and greatly reduce ND
>> flooding the same way they can reduce ARP flooding. So it seems very
>> simple to do.
>
>
> SeND has replay protection for solicited information (NA as a result 
> of a NS, RA as result of a RS) that uses nonces if I'm not mistaken.
> Since the nonce is protected by the signature, the rbridge can't 
> replay a NA/RA in response to a NS/RS, since it would be detected.
> (I think the unsolicited information uses a time stamp instead, which 
> allows for some amount of caching and replay by an rbride).
>
> But the packets still don't need to be flooded across the whole 
> topology since the first rbridge in the path can send the packet to 
> the last rbridge in the path, so that the host can respond.
>
>   Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0QN9WQ07815 for <[e-mail]>; Wed, 26 Jan 2005 15:09:32 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j0QN9WiI025670 for <[e-mail]>; Wed, 26 Jan 2005 15:09:32 -0800 (PST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0QN9VWJ458702; Wed, 26 Jan 2005 15:09:31 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2005 15:08:55 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RBridges and SEND/CGA
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 23:10:19 -0000
Status: RO
Content-Length: 1174

Eastlake III Donald-LDE008 wrote:
> One advantage of RBridges is that, with IP optimizations, they can do
> proxy ARP greatly reducing ARP flooding. I was thinking about whether
> this also applies to signed Neighbor Discovery messages in IPv6.
> Seems to me that it does.
> 
> In particular, if you pass along in the link state message not only
> MAC addresses but also the corresponding IP addresses and ND
> signatures, then the RBridges can do proxy ND and greatly reduce ND
> flooding the same way they can reduce ARP flooding. So it seems very
> simple to do.

SeND has replay protection for solicited information (NA as a result of 
a NS, RA as result of a RS) that uses nonces if I'm not mistaken.
Since the nonce is protected by the signature, the rbridge can't replay 
a NA/RA in response to a NS/RS, since it would be detected.
(I think the unsolicited information uses a time stamp instead, which 
allows for some amount of caching and replay by an rbride).

But the packets still don't need to be flooded across the whole topology 
since the first rbridge in the path can send the packet to the last 
rbridge in the path, so that the host can respond.

   Erik


Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0QLxFQ18455 for <[e-mail]>; Wed, 26 Jan 2005 13:59:15 -0800 (PST)
Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j0QM5XBR010519 for <[e-mail]>; Wed, 26 Jan 2005 15:05:33 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id j0QLvhWw013476 for <[e-mail]>; Wed, 26 Jan 2005 15:57:43 -0600
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <ZH8SSZX2>; Wed, 26 Jan 2005 16:59:13 -0500
Message-ID: <[e-mail]>
From: Eastlake III Donald-LDE008 <[e-mail]>
To: [e-mail]
Date: Wed, 26 Jan 2005 16:59:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] RBridges and SEND/CGA
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 22:00:17 -0000
Status: RO
Content-Length: 569

One advantage of RBridges is that, with IP optimizations, they can do proxy ARP greatly reducing ARP flooding. I was thinking about whether this also applies to signed Neighbor Discovery messages in IPv6. Seems to me that it does.

In particular, if you pass along in the link state message not only MAC addresses but also the corresponding IP addresses and ND signatures, then the RBridges can do proxy ND and greatly reduce ND flooding the same way they can reduce ARP flooding. So it seems very simple to do.

Has anyone else thought about this?

Thanks,
Donald