Subject: [Softwires] Ambiguity in MAP-E receiving rules

From: Tom Taylor <[email-masked]>
Date: Tue, 09 Jul 2013 11:06:38 -0400

Section 8.1 of draft-ietf-softwire-map talks about rules for processing 
incoming packets. The first paragraph says that the CE checks the 
received port number against the stateful port mapping table, but 
doesn't say what it does if the port is out of range.

I'm interested in whether the BR receives a notification when this 
happens (i.e., an ICMPv6 error message like the one described in the 
next paragraph going the other way). This would allow the BR to log the 
error.

Is the failure to specify CE action deliberate or should it be specified?

Tom Taylor

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 9 Jul 2013 17:58:13 +0200

The MAP-T draft actually covers that, with the following text. MAP-E should
do the equivalent with ICMPv4. Think the text on this  accidentally fell
through the cracks during the editorial cleanup.

The CE SHOULD check that MAP-T received
   packets' destination transport-layer destination port number is in
   the range allowed for by the CE's MAP BMR configuration.  The CE
   SHOULD drop any non conforming packet and respond with an ICMPv6
   "Address Unreachable" (Type 1, Code 3).

On 9 July 2013 17:06, Tom Taylor <[email-masked]> wrote:

> incoming packets. The first paragraph says that the CE checks the received
> port number against the stateful port mapping table, but doesn't say what
> it does if the port is out of range.
>
> I'm interested in whether the BR receives a notification when this happens
> (i.e., an ICMPv6 error message like the one described in the next paragraph
> going the other way). This would allow the BR to log the error.
>
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 9 Jul 2013 16:28:23 +0000

IMO, we should not specify this behavior at all, since it could provide a fantastic recipe for launching an attack against the BR. 

All the IPv4 packets failing the NAPT44 table check would result in ICMPv6 traffic to the BR. Sure, BR could do the rate-limiting of the incoming ICMPv6 packets, but it is consequential and should be avoided.

I suggest that the CPE should log this error in this case, and that's it. No need to notify the BR.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Wojciech Dec
> Sent: Tuesday, July 09, 2013 11:58 AM
> To: Tom Taylor
> Cc: Softwires
> Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules
> 
> 	Section 8.1 of draft-ietf-softwire-map talks about rules for
> processing incoming packets. The first paragraph says that the CE checks the
> received port number against the stateful port mapping table, but doesn't
> say what it does if the port is out of range.
> 
> happens (i.e., an ICMPv6 error message like the one described in the next
> paragraph going the other way). This would allow the BR to log the error.
> 
> 	_______________________________________________
> 	Softwires mailing list
> 	[email-masked]
> 	https://www.ietf.org/mailman/listinfo/softwires
> <https://www.ietf.org/mailman/listinfo/softwires>
> 
>

---

From: <[email-masked]>
Date: Thu, 11 Jul 2013 08:28:29 +0200

Hi Rajiv,

The problem is common for lw4o6 CPEs. It would make sense to have common
behaviour across the CPEs.

A couple of comments below.

Cheers,
Ian

On 09/07/2013 18:28, "Rajiv Asati (rajiva)" <[email-masked]> wrote:

>IMO, we should not specify this behavior at all, since it could provide a
>fantastic recipe for launching an attack against the BR.

[ian] Agreed

> 
>
>All the IPv4 packets failing the NAPT44 table check would result in
>ICMPv6 traffic to the BR. Sure, BR could do the rate-limiting of the
>incoming ICMPv6 packets, but it is consequential and should be avoided.
>

[ian] It may be useful to have the option of sending an ICMP error message
for troubleshooting. What about if we have a 'should' requirement for
logging the error on the CPE and a 'may' for sending an ICMP error message?

>>doesn't
>>next

---

From: Qi Sun <[email-masked]>
Date: Thu, 11 Jul 2013 20:47:35 +0800

Hi Rajiv,

IMHO, logging this kind of error on the BR may be useful for troubleshooting. 
But in the case that BR uses IPv6 anycast, the ICMPv6 packet replied by the CE could be sent to any of the BRs. Is it ok for any of the BRs to log the error, or the error should be logged by the specific BR that relays the incorrect packet to the CE?

Or this is not an issue?

Please correct me if I'm wrong.

Best Regards,
Qi

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 11 Jul 2013 13:15:43 +0000

Hi Ian,

We are in agreement. 

Even with MAY, We should add the cautionary note about ICMP usage.   

> behaviour across the CPEs.

I agree.

Cheers,
Rajiv

Sent from my Phone

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 11 Jul 2013 13:22:35 +0000

Hi Qi,

Good Q. Any BR should be enough to be notified, if notification were to be provided.

Cheers,
Rajiv

Sent from my Phone

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Jul 2013 09:38:00 -0400

>> No need to notify the BR.
[PTT] Is there any point to having the CPE generate logs? Who would look 
at them -- the operator or the customer? If logging is useful on the 
CPE, that should be reflected in our logging drafts, but if not, not.

> logging the error on the CPE and a 'may' for sending an ICMP error message?
...