Re: Source Address Dependent Routing and Source Address Selection for IPv6 - fate sharing

[Ray Hunter <[e-mail]>]

> Alexandru Petrescu <mailto:[e-mail]>
> 27 February 2015 14:23
> Le 25/02/2015 14:06, Ray Hunter a écrit :
>>> Alexandru Petrescu <mailto:[e-mail]> 24
>>> February 2015 16:18 Le 23/02/2015 17:40, V6ops a écrit :
>>>>
>>>>
>>>>> On 23 Feb 2015, at 10:55, Alexandru Petrescu
>>>>> <[e-mail]> wrote:
>>>>>
>>>>> Le 20/02/2015 21:46, V6ops a écrit :
>>>>>>
>>>>>>
>>>>>>> On 20 Feb 2015, at 17:51, Alexandru Petrescu
>>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>> Le 20/02/2015 13:23, Ole Troan a écrit :
>>>>>>>>>>
>>>>>>>>>> But why would one router need to point routes with
>>>>>>>>>> the next hop pointing at another router?
>>>>>>>>>
>>>>>>>>> BEcause that's how it works when two smartphones
>>>>>>>>> (Routers) talk directly over WiFi.  A Host device
>>>>>>>>> tethered to one smartphone would need to communicate to
>>>>>>>>> another Host tethered to the other smartphone. In this
>>>>>>>>> case, one smartphone (Router) would need to point a
>>>>>>>>> route with the next hop at the other smartphone
>>>>>>>>> (Router).
>>>>>>>>>
>>>>>>>>> The smartphone Router-to-Router is just an
>>>>>>>>> instantiation use-case. Another instantiation is in
>>>>>>>>> Vehicle-to-Vehicle communications.
>>>>>>>>
>>>>>>>> that's what we have redirects for.
>>>>>>>
>>>>>>> REdirects are sent by Routers to Hosts, not to other
>>>>>>> Routers.
>>>>>>>
>>>>>>> They assume some route is already in place (the route from
>>>>>>>  a Host to a Router) and that another one should be
>>>>>>> suggested - _re_-direct.
>>>>>>>
>>>>>>> In the case of smartphone-to-smartphone, or
>>>>>>> vehicle-to-vehicle, they may not be connected to anything
>>>>>>> else prior to connecting to each other, so they wouldnt
>>>>>>> issue Redirects.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>
>>>>>> And why exactly would a router listen to an RA then?
>>>>>>
>>>>>
>>>>> Sorry, I dont understand why you ask this?  Please clarify the
>>>>> question.
>>>>>
>>>>> Until then here's an answer about what I think the question is
>>>>>  not clear.
>>>>>
>>>>> A router would need to listen for RA issued by other router,
>>>>> such as to learn the prefix of this other Router's other
>>>>> interface.
>>>>
>>>> Where is this specified in a current IETF document?
>>>
>>
>>> In individual submissions such as the 'RA-based routing'
>> I've read these drafts. Thanks for the links.
>>> draft-petrescu-autoconf-ra-based-routing
>> OK. But this has a completely different RA option set and semantic
>> space, that is clearly only going to be processed by mobile routers.
>>  [new 'm' flag from 5175]
>>
>> I may or may not disagree with the proposal, but it's not going to
>> impact older nodes or non-mobile routers.
>
> I agree, these should ignore flags not understood.  In practice we have
> seen this M bit flag does not cause harm to other routers which do not
> understand it.
>
>>> with use-cases issued from the vehicular communications world; and
>>>  other similar mechanisms described in
>>> draft-pfister-moving-net-autoconf-00
>>
>> Again an 'm' flag for mobile use only.
>
> Yes, and this draft has a new 2-bit 'R' field to be considered in the
> future.  Some implementation of it specifies the extent of the
> propagation of the prefix, and maybe to more than just one hop.
>
>>> draft-jhlee-mext-mnpp-00
>>
>> Has a new ICMP type code for MNPP Solicitation and MNPP Advertisement
>> messages. It won't affect generic nodes.
>
> Ok.  The author will be happy to learn this, especially since that
> technique forms a basis for an ISO standard.
>
>>> draft-hampel-mext-ro-without-ha-00
>>
>> contains no new options AFAICS.
>
> Right.  It illustrates a Route Optimization path of development towards
> vehicle-to-vehicle communication, which considers Binding Updates
> instead of RAs.
>
>> My point is that none of these proposed extensions will likely be
>> processed by older nodes, or wired nodes, or Homenet nodes,
>
> Well.  A Homenet node must implement this technique when an automobile
> in the garage connects to the home hotspot (Tesla does this today).
>
> Will that Homenet node run HNCP or this M bit in a Router Advertisement?
>
>> so backwards compatibility and having to update generic (wired) nodes
>> is less of an issue for me.
>
> To a large extent yes.
>
>>>> Routers ignore RA in most instances ( unless they are acting as
>>>> a host on what is clearly an upstream interface, and they need
>>>> to configure a prefix for use on the upstream interface e.g. on
>>>> an ISP link)
>>>
>>> I agree.  But even this little detail (ignore RA unless acting as a
>>> host on a clearly identified upstream interface) is not explicitely
>>> stated anywhere.
>>
>> Agreed.
>>
>>>
>>>> Even in this case why would the RA require a different next hop
>>>> (my real confusion is why this option is needed at all)
>>>
>>> No, the next-hop comes from the src address of the RA.  But the
>>> prefix contained in the RA is the prefix of other link, not the
>>> prefix of the link on which this RA is sent.
>>
>> No, in Bechet's draft draft-sarikaya-6man-next-hop-ra-04, there's an
>>  explicit Next-Hop Address option proposed.
>>
>> That option only makes sense if it contains a next-hop address that
>> is different from the src address of the RA.
>>
>> That's exactly why I'm questioning the semantics of the new option
>> (e.g. with respect to the existing semantics of 4191).
>
> I agree.
>
> Moreover, putting a different next-hop address than src is less
> fate-sharing than putting a prefix present on the other link.
>
> Because whereas the prefix is of another link it is still on the same
> machine (its fate would still be shared, although not interface's), the
> next-hop is on another machine and another link.
>
> In that sense, if looking for as much as possible fate sharing one would
> consider the use of other link (same router) in the RA, rather than
> other address (other router) in the RA.
>
>>>> Homenet is not following this path for prefix
>>>> distribution/learning between LAN interfaces of Homenet devices
>>>> (one of the use cases of the draft). Two smartphones peering
>>>> would run HNCP to learn prefixes.... Not RA based mechanisms.
>>>
>>> Well, there should be a need for the HNCP to be first agreed on,
>>> and then to find widely available and reliable software.  With an
>>> RA-based scheme one would use already available software, with very
>>> small modifications, if any at all.
>>>
>>>>>
>>>>> A smartphone Router would send an RA on its bluetooth
>>>>> interface containing the prefix of its WiFi interface.
>>>>
>>>> This was already extensively discussed when producing
>>>> 464xlat.....
>>>
>>> I didnt know that.  I guess though 464xlat does not send RAs.
>>>
>>>>> An On-Board Unit Router would send an RA on its 802.11p
>>>>> (vehicle-to-vehicle) interface containing the prefix of its
>>>>> wired-Ethernet interface.
>>>>>
>>>>> Alex
>>>>
>>>> In general, I can certainly appreciate the need for a SADR
>>>> equivalent extension to 4191. But I'm mystified by the need for
>>>> the additional complexity contained in this draft. And I'm
>>>> genuinely missing how receiving nodes would process and validate
>>>>  the new options. I.e. The conceptual host model of 4191.
>>>
>>> I personally think at this time that SADR is a concept still much
>>> in an inception phase.  There are multiple ways in which the src
>>> address could be taken into account during a forwarding process.
>>> And I think it has little to do with RFC4191, or with what to put
>>> in an RA.
>>>
>>> The reason I react on this thread is only related to having other
>>> links' prefixes in an RA.
>>>
>> I find these use cases of an RA message containing information about
>>  off-link interfaces distinctly odd.
>
> Noted, but disagreeing.
>
>> RA is strictly link local (section 6.1.1 and 6.1.2 of RFC4861).
>>
>> Quote: "A node MUST silently discard any received Router
>> Advertisement messages that do not satisfy all of the following
>> validity checks:
>>
>> - IP Source Address is a link-local address."
>
> This is still the case: the src address of the RA containing the other
> interface's prefix is still that link-local address of that interface.
>
>> How does the receiving node know that the next hop is being
>> advertised from another interface on the sending router (there's no
>> interface tag in the proposed option)? [use case given by you of a
>> smart phone advertising its wifi prefix via the bluetooth interface]
>
> Well the receiving node does not need the src address of that other
> interface, because it is not in direct contact with it.  It needs the
> src address of the interface that sends the RA: through it it will reach
> the other link (immediate next-hop).
>
>> So in my mind that is introducing a possibility of non optimal
>> routing, race conditions, or worse still, looping (imagine the two
>> routers share two links, both wifi AND bluetooth, rather than just
>> one, and they pair at different times)
>
> Such possibilities may indeed be introduced.
>
> However, the precise case you cite (two routers share two links, both
> wifi and bluetooth) does not introduce any looping.  Simply only one
> route will be chosen among two present (2 redundant routes), depending
> on which was the last introduced.  One would rather think that it's
> better to have two routing paths always.
>
> Second, looping and other undesirable situations can be avoided by
> techniques yet to be developped as we encounter them in real-world
> use-cases.
Glad you're so positive about RA.
> The current trials (simple v2v communications) don't exhibit
> such undesirable IP routing situations.
>
> What are the use-cases which may exhibit non-optimal routing, race
> conditions and looping?
>


>> How does the receiving node know that the next hop target is to be
>> found on another interface on the receiving host (again there's no
>> interface tag in the proposed option)?
>
> The receiving node receives a prefix and installs it in its routing
> table with next-hop containing the src of the RA.  The receiving node
> does not run apps.
>
And why not? Are these devices so specific that they'll never ever be 
extended?
> Another node (a laptop in the car) uses its default route towards the
> 'receiving node' that we talk above.
>
>> [use case given by Bechet of a 3gpp router advertising next hop
>> addresses for use on the wireless interface on the receiving node
>> when connected to a VPN router]
>
> That is a use-case to which I dont agree.  NEver in practice a 3gpp
> router advertises an RA about another router outside the 3gpp network.
> That is a brokeness situation.
>
>> So in my mind that is introducing a possibility of non optimal
>> routing, or route attacks where routes received on a trusted
>> interfaces point to non-trusted interfaces, or an amplification
>> attack, where the receiving node has to perform ND on all of its
>> interfaces to discover where the proposed next hop is located
>> (assuming the advertised next hop actually contains garbage, and is
>> unreachable)
>
> Non optimal routing - I am curious to see where this situation can
> occur.  Otherwise stating it just as such may make think of speculation.
>  Yes, good in general to avoid non-optimal routing, but it does not
> exist everywhere.
Well it's pretty trivial to come up with problems. RA was designed to 
work over a single link, to communicate next hop information between an 
on-link router and an on-link host.

RA contains no explicit hop count. RA contains no explicit origin 
information. RA doesn't contain explicit timing or topology versioning 
information.

So taking your use case of a smart phone advertising a route to its wifi 
interface over bluetooth.....

if you have 4 such devices (Router_A, Router_B, Router_C, Router_D) 
behaving in the same way, connected say by Ethernet or an other 
multipoint segments [E1 ..E5] and with Prefix P1 on the ISP link, you have

ISP router ---E1-P1--- Router_A --- E2 --- Router_B --- E3 --- Router_C 
--- E4 --- Router_D --- E5

Which works fine and dandy in a linear or tree architecture.

Now connect E5 to E2, either temporarily or permanently. Router_B has no 
way of differentiating between an update from Router_D or an update from 
Router_A for Prefix P1.
The "metric" in RA is simply high medium or low. And that is a local 
preference. Not inherited or determined via other RA updates.

Similarly, Prefix 1 might be learned via being directly connected, or it 
might be learned via a routing protocol.
Router_B has no way of differentiating the origin of the information: it 
just receives reachability information.

And RA timing is only used for the next hop, which means Router_D has no 
idea of the current status of E3 or E2.

Well established routing protocols contain this extra information for a 
reason. Poor man's routing protocols (like RA) will inevitably break 
down when faced with real world topologies.

Deploying RA in these scenarios will require communicating much more 
extensive information than is currently contained in RA packets, in 
which case, why not just deploy a proper routing protocol in the first 
place?
>
> Amplification attack - yes we need to avoid an exponential growth of
> routing messages or of routing table entries provoked by the dynamic
> nature of mobility patterhs of devices such as vehicles.  But a
> receiving node does not perform ND on all of its interfaces to discover
> the proposed next hop.  A receiving node does just NS/NA for the src of
> the RA it received, on the interface it received it; that src address is
> also present on that link.  I do not propose to set garbage in the
> next-hop field of an RA.
>
Of course you won't send garbage in RA messages. But attackers will send 
garbage from the WAN link if it can cause an amplification attack on the 
LAN see e.g. https://tools.ietf.org/html/rfc6583.
> Alex
>
>
>>> Alex
>>>
>>>
>>> V6ops <mailto:[e-mail]> 23 February 2015 17:40
>>>> On 23 Feb 2015, at 10:55, Alexandru
>>>> Petrescu<[e-mail]>  wrote:
>>>>
>>>> Le 20/02/2015 21:46, V6ops a écrit :
>>>>>> On 20 Feb 2015, at 17:51, Alexandru Petrescu
>>>>>> <[e-mail]>  wrote:
>>>>>>
>>>>>> Le 20/02/2015 13:23, Ole Troan a écrit :
>>>>>>>>> But why would one router need to point routes with the
>>>>>>>>>  next hop pointing at another router?
>>>>>>>> BEcause that's how it works when two smartphones
>>>>>>>> (Routers) talk directly over WiFi.  A Host device
>>>>>>>> tethered to one smartphone would need to communicate to
>>>>>>>> another Host tethered to the other smartphone. In this
>>>>>>>> case, one smartphone (Router) would need to point a route
>>>>>>>> with the next hop at the other smartphone (Router).
>>>>>>>>
>>>>>>>> The smartphone Router-to-Router is just an instantiation
>>>>>>>> use-case. Another instantiation is in Vehicle-to-Vehicle
>>>>>>>> communications.
>>>>>>> that's what we have redirects for.
>>>>>> REdirects are sent by Routers to Hosts, not to other
>>>>>> Routers.
>>>>>>
>>>>>> They assume some route is already in place (the route from a
>>>>>>  Host to a Router) and that another one should be suggested
>>>>>> - _re_-direct.
>>>>>>
>>>>>> In the case of smartphone-to-smartphone, or
>>>>>> vehicle-to-vehicle, they may not be connected to anything
>>>>>> else prior to connecting to each other, so they wouldnt issue
>>>>>> Redirects.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>> And why exactly would a router listen to an RA then?
>>>>>
>>>> Sorry, I dont understand why you ask this?  Please clarify the
>>>> question.
>>>>
>>>> Until then here's an answer about what I think the question is
>>>> not clear.
>>>>
>>>> A router would need to listen for RA issued by other router, such
>>>> as to learn the prefix of this other Router's other interface.
>>> Where is this specified in a current IETF document?
>>>
>>> Routers ignore RA in most instances ( unless they are acting as a
>>> host on what is clearly an upstream interface, and they need to
>>> configure a prefix for use on the upstream interface e.g. on an ISP
>>> link)
>>>
>>> Even in this case why would the RA require a different next hop (my
>>> real confusion is why this option is needed at all)
>>>
>>> Homenet is not following this path for prefix distribution/learning
>>> between LAN interfaces of Homenet devices (one of the use cases of
>>> the draft). Two smartphones peering would run HNCP to learn
>>> prefixes.... Not RA based mechanisms.
>>>> A smartphone Router would send an RA on its bluetooth interface
>>>> containing the prefix of its WiFi interface.
>>> This was already extensively discussed when producing 464xlat.....
>>>
>>>> An On-Board Unit Router would send an RA on its 802.11p
>>>> (vehicle-to-vehicle) interface containing the prefix of its
>>>> wired-Ethernet interface.
>>>>
>>>> Alex
>>>
>>> In general, I can certainly appreciate the need for a SADR
>>> equivalent extension to 4191. But I'm mystified by the need for the
>>> additional complexity contained in this draft. And I'm genuinely
>>> missing how receiving nodes would process and validate the new
>>> options. I.e. The conceptual host model of 4191.
>>>
>>
>

-- 
Regards,
RayH