[rbridge] ARP proxying

[Gray, Eric]

Joe,

	Your references to RFC 3756 and RFC 3971 are just a bit opaque.
Would you care to expand on what the relationship might be between what 
we're talking about and IPv6 neighbor discovery security issues?

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Tuesday, December 20, 2005 2:32 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Guillermo Ibáñez wrote:
--> > I agree we must look for a different term.
--> > English is not my mother tongue so I beg your pardon in 
--> advance if it 
--> > sounds bizarre (weird). How about ARP "recording"  or 
--> "storing" (just to 
--> > differentiate). 
--> 
--> These are nuances on the idea of caching - they address 
--> capturing and
--> retaining ARPs seen on the net. The key feature of what is being
--> proposed is to then replay them as if they came from the 
--> original source.
--> 
--> I found a couple of other possibilities, but each isn't as 
--> accurate as
--> replay, IMO:
--> 
--> 	- repeater
--> 		typically this indicates the copy of an incoming frame
--> 		is sent on an outgoing link; in our case, we want the
--> 		copy to be generated in response to the ARP request,
--> 		not just to relay the ARP reply
--> 
--> 	- relay
--> 		same issue as repeater
--> 
--> IMO, replay is the most accurate for this kind of optimization, with
--> 'spoofing' just as accurate but with a strong hint that the 
--> spoofer is
--> malicious.
--> 
--> PS - it would be useful to see RFC3756 regarding this 
--> issue, and RFC3971
--> which appears to defeat such optimization in an rbridge.
--> 
--> - ----
--> 
--> That said, I agree with Radia if the term "ARP/ND 
--> optiimization" is the
--> general term. I also agree that replying with the 
--> destination's MAC is
--> the right answer; at no point should non-Rbridge nodes on 
--> the net ever
--> know - or need to know - about the MAC of an rbridge device, IMO.
--> 
--> > In the drat Abridges I use ARP "registering", but this 
--> > is an intentional operation.
--> 
--> That sounds right for what is intended there.
--> 
--> Joe
--> 
--> > Guillermo
--> > 
--> > Gray, Eric wrote:
--> > 
--> > 
--> >>Joe,
--> >>
--> >>--> > 	The fact that RFC 925 describes using a cache or ARP 
--> >>--> > entries as a basis for what RFC 1009 subsequently defines as
--> >>--> > ARP caching (or "the ARP hack"), in no way implies 
--> that this 
--> >>-->
--> >>--> proxy ARP in 1009. 
--> >>
--> >>Yeah, meant to say "proxy ARP" instead of "ARP caching".
--> >>
--> >>--> > is what anyone would generally refer to as ARP caching.  In
--> >>--> > fact, one use for the cache defined in RFC 925 is the MAC DA
--> >>--> > "translation" that occurs in traversing an Internet Gateway
--> >>--> > (router).
--> >>--> 
--> >>--> Except that the rules for ARP caching are the same 
--> for all ARP caches -
--> >>--> regarding cache refresh, timeout, etc. That's why 
--> it's useful and
--> >>--> important to consider them equivalent.
--> >>
--> >>Earlier (Friday, 12/16), in a post on this same subject, 
--> Radia said
--> >>(in part) 
--> >>
--> >> 
--> >>
--> >>
--> >>>>b) getting rid of stale ARP caches faster by sometimes 
--> (we'd have 
--> >>>>to decide >>under what circumstances) sending the ARP 
--> query directly
--> >>>>to the assumed target's link, and making the target respond.
--> >>>>     
--> >>>>
--> >>
--> >>I am unclear how this behavior is a significant departure from a
--> >>typical ARP cache implementation in a host or router.
--> >>
--> >>--> > 	While it is clearly too late to change the prior usage,
--> >>--> > the function described in RFC 1009 would be better termed an
--> >>--> > "ARP Translation" than an "ARP Proxy".
--> >>--> 
--> >>--> That would require our redefining that term, as well 
--> as corresponding
--> >>--> proxy terms in other widespread use - notably web proxy. 
--> >>
--> >>Argument for the sake of argument.  You and I both agree that
--> >>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
--> >>That was abundantly clear in the remainder of the text, as was
--> >>also the fact that I am not arguing to change the past.
--> >>
--> >>--> Proxying in these cases, as well as in general English, 
--> >>--> refers to one party _representing_ another, not trying to 
--> >>--> fake being another.
--> >>
--> >>Exactly!  Glad we agree...
--> >>
--> >>--> > 	I think many of us are convinced that "ARP Proxy" can't
--> >>--> > be used because of earlier (historical) reasons (whether we
--> >>--> > regard those as in error or not).  I do not think the term
--> >>--> > "ARP Replay" is sufficiently descriptive and I believe that
--> >>--> > the suggestion is made pejoratively - in what 
--> certainly looks
--> >>--> > like an attempt to prejudice the working group against any
--> >>--> > such discussion.
--> >>--> 
--> >>--> This _is_ a replay, with all the good AND bad 
--> associations. It's
--> >>--> useful to consider those issues, e.g., that replay 
--> won't work if
--> >>--> proper anti-replay measures are implemented.
--> >>
--> >>I disagree.  Apparently, your offer for someone else to suggest a
--> >>term was not genuine as you appear unwilling to accept any such
--> >>suggestion.
--> >>
--> >>Or perhaps it is just me.  Anybody else care to suggest a term?
--> >>
--> >>--> -----Original Message-----
--> >>--> From: rbridge-bounces at postel.org 
--> >>--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> >>--> Sent: Monday, December 19, 2005 11:22 AM
--> >>--> To: Developing a hybrid router/bridge.
--> >>--> Subject: Re: [rbridge] ARP proxying
--> >>--> 
--> >>--> _______________________________________________
--> >>--> rbridge mailing list
--> >>--> rbridge at postel.org
--> >>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>--> 
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>rbridge at postel.org
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>
--> >> 
--> >>
--> > 
--> > 
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDqFwpE5f5cImnZrsRAhhIAJ0SoTf2TX2YFrx8FTSYt9j97B/cYwCeLpaG
--> lY0fTqVQ3AMYFHRdqPTQLGE=
--> =7HhS
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->