Subject: RE: RFC 6724 and draft-baker-6man-multi-homed-host

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 1 Sep 2015 19:25:55 +0000

Hi routing experts,

Can somebody review the use cases below please? The idea is to identify possible failure paths based on a wrong source address selection. Then we should verify if the source-address-based first hop router selection will solve the problems. One failure path is a source address ingress filtering while sending a packet. That one was frequently mentioned. Use cases below try to identify return paths where the replies will not reach the originator. This needs to be verified and clarified. 

Other use cases are desirable, especially those showing that the proposed solution will not solve the problem.

Thanks,
Dusan.

-----Original Message-----
From: Mudric, Dusan (Dusan) 
Sent: Thursday, August 27, 2015 9:58 AM
To: 'Brian E Carpenter'; 神明達哉
Cc: [email-masked]
Subject: RE: RFC 6724 and draft-baker-6man-multi-homed-host

The idea is to identify use cases (a problem statement) where a wrong source address selection and router selection will cause problems. The algorithm needs to show that the these problems will be avoided.

Let's say provider 2 does not apply ingress filtering. If provider 0, where multi-homed host is, provides ingress filtering and host selects a wrong source address when sending a request, what can happen with a reply from Provider 2? It is possible that the reply in the reverse path reaches rtr1 because the destination address in the reply is based on rtr1 prefix and rtr1 advertised a default router for that prefix. If rtr1 applies ingress filtering expecting only packets from Provider1 subnet, the replies will not reach the host in Provider 0.

If the above is true, the source address based router selection by the host is important even if Provider 2 does not apply ingress filtering but Provider 0 does. If that is the case, the problem statement needs one more use case. If a right source address and a rtr2 are selected, a reply from Provider 2 will reach rtr2, not rtr1. If rtr2 enables either ingress filtering or "Source/Destination Routing" filter, the reply will reach the host.

Use case 3 can be: host selected the source address based on rtr1 prefix and sent the packet over rtr2. The Provider 2 (that does not provide ingress filtering) reply comes to rtr2 which implements "Source/Destination Routing" filter. If the destination is constrained only to the prefix rtr2 advertised to the host, the reply will not reach the host. If a right source address and a rtr2 are selected, and reply from Provider 2 reaches rtr2, "Source/Destination Routing" filter on rtr2 will not discard the replies.

   (Provider 0)
      +------+
      |          |           +------+                                                +---------
      |          |           |          |      (Network)                     /
      |          |=+===| rtr1 |====|(Provider 1)|=====|
      |          |  |       |         |                                             |
      |          |  |       +------+                                             |
      | host |  |                                                                  |    Internet
      |          |  |                                                                  |
      |          |  |    +------+                                                 |
      |          |  |    |          |      (Network)                        |
      |          |  +==| rtr2 |====|(Provider 2)|=======|
      |          |        |          |                                                  \
      +------+         +------+                                                    +----------

            Figure 5: Simple Home Network with Two CPE Routers

The same applies to figures 1 and 4.

Regards,
Dusan.

>> How is the host network in Figure 5 of 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dsarikaya-2D6man-2Dsadr-2Doverview_-3Finclude-5Ftext-3D1&d=BQICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=1UAeb-kJWiAWRIV0ZYHhEmLtuS_V67mtRsTJkIhTBfs&s=COHtP0gVqoYwMdLlNA1iFEPLarWk-innqbVIj4wtoW4&e=  going to do ingress filtering of the replies? If the host selects a source address based on Router 1 prefix and sends a packet over Routre 2, what will happen with the reply?
>> 

I'm not sure I understand the question. If Provider 2 is applying a BCP38 filter, the packet will be dropped and there is no reply. If it's not filtering, what's the problem? Routes don't have to be symmetric.

Regards
    Brian

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 1 Sep 2015 19:37:52 +0000

Hi Brian,

SASA rule 5.5 assumes the destination D is reachable over the first hop router. I already asked about the "Reachability" of the D from host perspective:

"We also need to answer questions regarding SASA rule 5.5. The rule says to select the next-hop that will be used to send to D. It does not say how to select the next-hop. We need exact steps to make sure the first hop router is always properly selected. What are the steps to select the next-hop based on the destination IPv6 address?"

The question needs to be answered. If the first hop router succeeds only in 95% to provide reachability information to D, SASA rule 5.5 will return the right source address for more than 95% of the requests. To have accurate outcome of SASA rule 5.5, we need an extension. What else needs to be done? Is it a trace route to D: http://www.iij-ii.co.jp/en/lab/researchers/cristel/publications/Lutu-visibility-PAM2014.pdf ?

Regards,
Dusan.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, August 31, 2015 5:57 PM
To: Mudric, Dusan (Dusan); 神明達哉
Cc: [email-masked]
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host

Dusan,

I think we're miscommunicating. Yes, someone who implements our draft will have to augment their sending code and implement address selection rule 5.5.
But from a formal point of view that doesn't invalidate or update 4861 or 6724.

Of course, you can't create the "history" until after a successful round trip.
So there's another missing piece in the whole puzzle, which is what happens if the first address pair that you try fails to connect. That's a much broader question (cf the "Reachability of distributed prefixes" thread on homenet).

Regards
   Brian

On 01/09/2015 08:47, Mudric, Dusan (Dusan) wrote:
> Hi Brian,
> 
> How did you conclude that I am mixing the source address selection with the first hop selection? I joined the conversation when you "Agreed" that the draft is about how to "choose the right default router for a given source address". I was the one that pointed out that it is opposite and asked to clearly describe the distinction and dependencies between RFCs 6724 and 4861. Some updates were made after my comments: 
> 
>> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbaker-2D6man-2Dmulti-2Dhomed-2Dhost-2D02&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=IbxK_IXn_y7zFuoQD4lzFQye0gOz5f2yvE4sZbycEZ4&s=pBvsn1TWUHlCTGgjUdBiU1iNjoYD8GIQt3rBZQFL5EU&e=
> 
> Even after updates, I don't believe the draft provides a clear problem statement and a solution. It fails to recognize the importance of RFC 6724 rule 5.5 and does not define a solution in the realm of existing standards for host. The draft does not recognize the solution is a part of the sending algorithm. The draft still talks about hosts maintaining 'history' of the next hop address used. It proposes a use of result of a 'successful' connection with a destination: "When a host makes a successful exchange with a remote destination ... then the host SHOULD include the prefix in such history". This is wrong. The host should first select next hop (RFC 6724 rule 5.5), then source address (RFC 6724 rule 5.5), then send the packet (using the selected source address to find the next hop by matching the address prefix). So, nothing is sent ("exchanged with a remote destination") before the next hop router and the source address are selected.
> 
> That is why provided a full definition on 8/24/2015 (please see below). Please identify what will not work in this definition and where the source address selection and the first hop selection are mixed up.
> 
> ======================================================================
> ==================================
> 3. Reasonable expectations of the host
> 	   There is an interaction with Default Address Selection [RFC6724].	
> 	   Rule 5.5 of that specification states that the source address used when	
> 	   sending to a given destination address should, if possible, be chosen for	
> 	    a prefix known to be advertised by the first-hop router for that	
> 	   destination.  This draft defines rules how hosts remember which first-hop routers
>                  advertised which prefixes and how to use these prefixes while sending packets.
> 
> 3.1 Sending Algorithm
> RFC 4861, section 5.2, defines sending algorithm. It uses a combination of the Destination Cache Entry (DCE) table, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop. The next hop can be either on-link neighbor or a first hop router. If there is no DCE table entry that matches the destination address and there is no matching destination address prefix in the Prefix List, a packet is sent to the selected first hop router. RFC 4861, section 6.3.6,  "Default Router Selection" selects the first hop router based the router reachability or a round-robin fashion. This algorithm does not guarantee the packet from a multi-homed hosts will be sent via the next hop to the destination D. This draft defines further improvements to RFC 4861 to facilitate better first hop router selection.
> 
> When a host receives RA message, RFC 4861 section 6.3.4 "Processing Received Router Advertisements" needs to add that the host should update the entry in the Default Router List with the list of prefixes the router advertised. When a prefix is removed from the Prefix List, it must be removed from the entry in the Default Router List.
> 
> When a multi-homed host is sending a packet to off-link destination, it will first select a source address. RFC 6724 SASA rule 5.5 might be used to select the source address. The packet has matching {Source_IP, Destianton_IP} pair needed to pass ISP ingress filtering. The next step is a first hoop router selection. The existing RFC 4861 "Default Router Selection" needs to be modified to use the SASA selected source address for the next hope router selection. During the default router selection the host will prefer the entry from the Default Router List which has the prefix of the selected source address. The selected next hop entry is put in the DCE table. The packet is sent over the selected first hop router. Destination ISP network ingress filtering will not discard the packet because the source address has the matching prefix for the destination subnet. Subsequent packets are sent based on the destination IPv6 address and the DCE table entry match.
> 
> Assumption of rule SASA 5.5  is that the SASA selected source address is based on an advertised prefix. If destination D is reachable over the first hop that did not advertise the address prefix, the implementation should add the destination address to the first-hop router entry in the Default Router List. This address can be used during Default Router Selection to select the first hop router for the off-link destination address.
> ======================================================================
> ==================================
> 
> Regards,
> Dusan Mudric.
> 
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, August 27, 2015 3:31 PM
> To: Mudric, Dusan (Dusan); 神明達哉
> Cc: [email-masked]
> Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host
> 
> Hi Dusan,
> 
> 
> On 28/08/2015 01:58, Mudric, Dusan (Dusan) wrote:
>> Let's say provider 2 does not apply ingress filtering. If provider 0, where multi-homed host is, provides ingress filtering and host selects a wrong source address when sending a request, what can happen with a reply from Provider 2?
> 
> Again you are mixing source address selection and first hop selection. The draft is about first hop selection and it's about outbound packets. Of course the identical problem may exist at the other end for the return packets, but that doesn't change the arguments, it just moves them to the other end.
> 
> Let's keep this draft as simple as possible.
> 
>     Brian
> 
>> It is possible that the reply in the reverse path reaches rtr1 because the destination address in the reply is based on rtr1 prefix and rtr1 advertised a default router for that prefix. If rtr1 applies ingress filtering expecting only packets from Provider1 subnet, the replies will not reach the host in Provider 0.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Sep 2015 08:32:43 +1200

> "We also need to answer questions regarding SASA rule 5.5. The rule says to select the next-hop that will be used to send to D. It does not say how to select the next-hop. We need exact steps to ma…

That is completely out of scope for this draft.

    Brian

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 2 Sep 2015 14:18:47 +0000

The improved first hope router selection algorithm increases probability that  the packet from a multi-homed hosts will be sent via a correct first hop router to an off-link destination D. This algorithm still does not guarantee the packet from the multi-homed hosts will be sent via the first hop router to the off-link destination D. The selected router can further help multi-homed single-link hosts to select a better first hop router using Redirect message. Further investigation needs to be done for multi-homed multi-link hosts, where Redirect cannot be used. 

This draft is based on the assumption that an off-link destination D is reachable while applying SASA rule 5.5. Only for the reachable destination the endpoint will be able to select the source address whose prefix was advertised by the first hop router. This has to be clearly stated in the draft. That is the key assumption. The draft also has to state that since the reachability is not 100% guaranteed, further research needs to be done to improve the first hope router selection algorithm (either to improve the next hop search algorithm while doing SASA rule 5.5 (e.g. improve host routing table updates) and/or while doing the first hop router selection using the ND Default Router List).

I believe with these additions and prior definitions and problem statements, the draft will be well rounded.

Regards,
Dusan.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, September 01, 2015 4:33 PM
To: Mudric, Dusan (Dusan); 神明達哉
Cc: [email-masked]
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host

    Brian

> 
> The question needs to be answered. If the first hop router succeeds only in 95% to provide reachability information to D, SASA rule 5.5 will return the right source address for more than 95% of the requests. To have accurate outcome of SASA rule 5.5, we need an extension. What else needs to be done? Is it a trace route to D: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iij-2Dii.co.jp_en_lab_researchers_cristel_publications_Lutu-2Dvisibility-2DPAM2014.pdf&d=BQIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=CTbRqwovEUcfjgq1m4ccUu_-C2WEqdArmJryEBgnTZ0&s=oC5NbBZVD3ykVE2GY-BgVcZhnYu3pBasr1NGvG6J37k&e=  ?
> 
> Regards,
> Dusan.
>