Subject: [Softwires] Fragmentation in sdnat-02

From: Washam Fan <[email-masked]>
Date: Wed, 21 Mar 2012 14:25:12 +0800

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

---

From: <[email-masked]>
Date: Wed, 21 Mar 2012 11:24:48 +0100

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 : [email-masked] 
>[mailto:[email-masked]] De la part de Washam Fan
>Envoyé : mercredi 21 mars 2012 07:25
>À : Softwires
>Objet : [Softwires] Fragmentation in sdnat-02
>
>Hi Authors,
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires
>

---

From: GangChen <[email-masked]>
Date: Thu, 22 Mar 2012 15:33:15 +0800

2012/3/21, [email-masked] <[email-masked]>:
> 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#section-4.5.2.

BRs

Gang

---

From: <[email-masked]>
Date: Thu, 22 Mar 2012 08:51:59 +0100

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

>De : GangChen [mailto:[email-masked]] 
>Envoyé : jeudi 22 mars 2012 08:33
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Washam Fan; Softwires
>Objet : Re: [Softwires] Fragmentation in sdnat-02
>
>> This is an issue common to all stateless solutions, 
>including deterministic
>> NAT with (anaycast) IPv4 address pool.
>>

---

From: GangChen <[email-masked]>
Date: Thu, 22 Mar 2012 17:53:00 +0800

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

---

From: Washam Fan <[email-masked]>
Date: Fri, 23 Mar 2012 10:08:39 +0800

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 10:02:19 +0100

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

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 10:16:53 +0100

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 

>De : Rémi Després [mailto:[email-masked]] 
>Envoyé : vendredi 23 mars 2012 10:02
>Cc : GangChen; Softwires
>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
>- 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.
>> Thanks, but I failed to find the text describing how to 
>handle two fragments received by two distinct BRs.
>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 11:01:40 +0100

> 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

>>>> ion-4.5.2.

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 14:59:28 +0100

Hi, Washam,

> first place. Remi, could you clarify on this?

Not sure to understand the question.
IPv4 routing toward BRs is based on IPv4 prefixes (which are anycast by nature).

RD

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 10:58:09 +0200

>   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

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 11:05:48 +0200

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

PS: I don't believe which should say more.