Re: [Softwires] Fragmentation in sdnat-02
In your previous mail you wrote: This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. = +1! In fact, it is an issue common to all solutions implying mandatory filtering on transport fields (aka layer 4) including ports. Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
In your previous mail you wrote: In this context, the important consideration is AFAIK that it is completely acceptable to lose fragmented packets that, with bad luck, happen to be routed via distinct BRs when there is a route change. Frequent route changes would have many more severe consequences than this one if considered normal. Do we agree on this? = I agree (BTW in my comments about SD-NAT I warned than even with the no-translation on the SD-CGN variant there is still a mandatory reassembly which means incomplete fragmented packets are dropped). Regards francis.dup...@fdupont.fr PS: I don't believe which should say more. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Hi, Med, Thanks for this question. 1. As we know, all fragments of a packet from a given off-domain host to a given in-domain IPv4 address usually enter the domain via the same BR. (Otherwise packet disordering would badly disrupt TCP). 2. When fragments of a packet enter a domain via distinct BRs (e.g. due to some change in routing or load balancing information bases), the algorithm of http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. (3) is such that the packet will be lost: - A fragments going via a BR that didn't receive the first fragment is discarded by this BR. This results from the last column of the decision table. - Reassembly in the destination becomes therefore impossible. OK? Cheers, RD Le 2012-03-22 à 08:51, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Hi Rémi, This is well understood. The issue and the behaviour you are describing is common to all address sharing solutions with or without NAT; including all A+P flavours (MAP, 4rd, SDNAT). The point is: ** IF ** the issue raised by Washam is judged ** SEVERE ** issue, consider the solution presented in http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : vendredi 23 mars 2012 10:02 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 Hi, Med, Thanks for this question. 1. As we know, all fragments of a packet from a given off-domain host to a given in-domain IPv4 address usually enter the domain via the same BR. (Otherwise packet disordering would badly disrupt TCP). 2. When fragments of a packet enter a domain via distinct BRs (e.g. due to some change in routing or load balancing information bases), the algorithm of http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. (3) is such that the packet will be lost: - A fragments going via a BR that didn't receive the first fragment is discarded by this BR. This results from the last column of the decision table. - Reassembly in the destination becomes therefore impossible. OK? Cheers, RD Le 2012-03-22 à 08:51, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Le 2012-03-23 à 10:16, mohamed.boucad...@orange.com a écrit : Hi Rémi, This is well understood. The issue and the behaviour you are describing is common to all address sharing solutions with or without NAT; including all A+P flavours (MAP, 4rd, SDNAT). The point is: ** IF ** the issue raised by Washam is judged ** SEVERE ** issue, consider the solution presented in http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. In this context, the important consideration is AFAIK that it is completely acceptable to lose fragmented packets that, with bad luck, happen to be routed via distinct BRs when there is a route change. Frequent route changes would have many more severe consequences than this one if considered normal. Do we agree on this? Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : vendredi 23 mars 2012 10:02 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 Hi, Med, Thanks for this question. 1. As we know, all fragments of a packet from a given off-domain host to a given in-domain IPv4 address usually enter the domain via the same BR. (Otherwise packet disordering would badly disrupt TCP). 2. When fragments of a packet enter a domain via distinct BRs (e.g. due to some change in routing or load balancing information bases), the algorithm of http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. (3) is such that the packet will be lost: - A fragments going via a BR that didn't receive the first fragment is discarded by this BR. This results from the last column of the decision table. - Reassembly in the destination becomes therefore impossible. OK? Cheers, RD Le 2012-03-22 à 08:51, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Hi, Washam, Le 2012-03-23 à 03:08, Washam Fan a écrit : There is no text saying 4rd-u BRs are anycasted to IPv4 network in the first place. Remi, could you clarify on this? Thanks, washam Not sure to understand the question. IPv4 routing toward BRs is based on IPv4 prefixes (which are anycast by nature). RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Dear Med, Yes. There are no texts targeting to this topics. I mean we could leverage the consideration in 4rd-U to build a entry table. One more REDIRECTION action obviously should be added to the row of RESULTING ACTIONS. Any received fragment looking for conditions and execute a proper action(forwarding or redirection) BRs Gang 2012/3/22, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
