[rbridge] RBridges and SEND/CGA

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

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
From erik.nordmark at sun.com  Thu Jan 27 13:47:22 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu Jan 27 13:48:22 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

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
From touch at ISI.EDU  Thu Jan 27 15:12:52 2005
From: touch at ISI.EDU (Joe Touch)
Date: Thu Jan 27 15:14:48 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>



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
-------------- 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/20050127/9f1f11ad/signature.bin
From greg.daley at eng.monash.edu.au  Thu Jan 27 16:19:17 2005
From: greg.daley at eng.monash.edu.au (Greg Daley)
Date: Thu Jan 27 16:20:51 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

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.
From greg.daley at eng.monash.edu.au  Thu Jan 27 16:30:40 2005
From: greg.daley at eng.monash.edu.au (Greg Daley)
Date: Thu Jan 27 16:32:24 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>

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
From touch at ISI.EDU  Thu Jan 27 16:45:38 2005
From: touch at ISI.EDU (Joe Touch)
Date: Thu Jan 27 16:47:14 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>
	<[e-mail]>	<[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>



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
-------------- 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/20050127/c8bafbfc/signature.bin
From erik.nordmark at sun.com  Thu Jan 27 16:55:33 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu Jan 27 16:58:25 2005
Subject: [rbridge] RBridges and SEND/CGA
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

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