Subject: [BEHAVE] text on nat64 about sending imcp unreachable packets for protocols other than TCP, UDP, ICMP

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 28 Mar 2010 20:48:51 +0200

As agreed in the meeting, i propose to add the following text to the 
stateful draft:

<t>If the incoming packet is an IPv6 packet that contains a protocol 
other than TCP, UDP or ICMPv6, then
the packet is discarded and, if the security policy permits, the NAT64 
SHOULD send an ICMPv6 Destination Unreachable error message
with Code 3 (Destination Unreachable) to the source address of the 
received packet.</t>

<t>If the incoming packet is an IPv4 packet that contains a protocol 
other than TCP, UDP or ICMPv4, then
the packet is discarded and, if the security policy permits, the NAT64 
SHOULD send an ICMPv4 Destination Unreachable error message
with Code 2 (Protocol Unreachable) to the source address of the received 
packet.</t>

Let me know if you have comments

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Mar 2010 10:19:57 +1300

> with Code 3 (Destination Unreachable) to the source address of the

Should you clarify that this refers to the *last* Next Header?

Also, should there be a note that future documents might modify
this requirement for SCTP and DCCP?

> with Code 2 (Protocol Unreachable) to the source address of the received

That made me wonder what a stateful NAT64 should do in general about
Protocol 41 inside an IPv4 packet. Maybe that's already discussed elsewhere?

   Brian
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 28 Mar 2010 23:49:06 +0200

> Should you clarify that this refers to the *last* Next Header?
agree, will add that

> this requirement for SCTP and DCCP?
i can add a note about that as well

> Protocol 41 inside an IPv4 packet. Maybe that's already discussed elsewhere?
no, afaict
i am not sure what the proper behaviour would that be. If the IPv4 dst 
address is one of the nat64 box, the nat64 could extract the ipv6 packet 
and forward it. but i guess this is not because it is a nat64 box, but 
because it is the endpoint of a tunnel, which behaviour is specifed 
soemwhere else. If the ipv4 dst address is not one fo the nat64 box, i 
don't think the packet should have got there anyway.

So, i dont think there is anything special about the nat64 in this... am 
i missing something?

Regards, marcelo

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sun, 28 Mar 2010 15:15:05 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of marcelo bagnulo braun
Sent: Sunday, March 28, 2010 2:49 PM
To: Behave WG; 'Magnus Westerlund'; Behave Chairs; David Harrington
Subject: [BEHAVE] text on nat64 about sending imcp unreachable packets
for protocols other than TCP, UDP, ICMP

<t>If the incoming packet is an IPv6 packet that contains a protocol
other than TCP, UDP or ICMPv6, then the packet is discarded and, if the
security policy permits, the NAT64 SHOULD send an ICMPv6 Destination
Unreachable error message with Code 3 (Destination Unreachable) to the
source address of the received packet.</t>

[Senthil] Does "packet is discarded" mean MUST/SHOULD/MAY be discarded ?
How about GRE or other tunnel protocols? What about ESP?

<t>If the incoming packet is an IPv4 packet that contains a protocol
other than TCP, UDP or ICMPv4, then the packet is discarded and, if the
security policy permits, the NAT64 SHOULD send an ICMPv4 Destination
Unreachable error message with Code 2 (Protocol Unreachable) to the
source address of the received packet.</t>

[Senthil] Same as above. 

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 29 Mar 2010 09:28:21 +0200

> [Senthil] Does "packet is discarded" mean MUST/SHOULD/MAY be discarded ?
MUST be discarded, i rephrased the text to make this clear.

> How about GRE or other tunnel protocols? What about ESP?
The WG agreed in the dublin meeting that the nat64 scope will be limited 
to TCP, UDP and ICMP.

Support for all other protocols will be defined in future specs. This is 
expliclty stated in the NAT64 document.

> source address of the received packet.</t>
same replies.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Mar 2010 01:57:26 +1300

Just on the Protocol 41 question:

> El 28/03/10 23:19, Brian E Carpenter escribió:

...

> So, i dont think there is anything special about the nat64 in this... am

Your two cases suggest to me that a NAT64 should never see such packets.
If it is in the same box as a 6-in-4 tunnel endpoint the decapsulation
should have happened already and if the packet is just passing through
it seems like a misconfiguration. So maybe this is a SHOULD discard
(SHOULD just in case there is a legitimate case that we can't see
right now).

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 29 Mar 2010 15:12:27 +0200

> (SHOULD just in case there is a legitimate case that we can't see
mmm, i don't have a strong preference here

I was using MUST cause that is what we agreed in the meeting, but if 
people think it is better to have a should, i am ok as well.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Mar 2010 09:21:00 +1300

I have no real objection to MUST discard, if that
avoids changing the text. Just wanted to check that
protocol 41 wasn't a special case.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Mar 2010 16:52:47 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, March 29, 2010 1:21 PM
> To: marcelo bagnulo braun
> Cc: David Harrington; Behave WG; Behave Chairs
> Subject: Re: [BEHAVE] Proto 41 [text on nat64 about sending 
> imcp unreachable packets for protocols other than TCP, UDP, ICMP]
> 

If you're asking now, someone else will wonder after the document
is published.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Mar 2010 10:08:19 +0200

my reading of the WG consensus is that we should go for a should on this.
is that ok?

El 30/03/10 1:52, Dan Wing escribió:
>>>>>> That made me wonder what a stateful NAT64 should do in
>>>>>>              
>> general about
>>      
>>>>> i am not sure what the proper behaviour would that be. If
>>>>>            
>> the IPv4 dst
>>      
>>>>> address is one of the nat64 box, the nat64 could extract
>>>>>            
>> the ipv6 packet
>>      
>>>>> and forward it. but i guess this is not because it is a
>>>>>            
>> nat64 box, but
>>      
>>>>> because it is the endpoint of a tunnel, which behaviour
>>>>>            
>> is specifed
>>      
>>>>> soemwhere else. If the ipv4 dst address is not one fo the
>>>>>            
>> nat64 box, i
>>      
>>>>> So, i dont think there is anything special about the
>>>>>            
>> nat64 in this... am
>>      
>>>>> i missing something?
>>>>>
>>>>>            
>>>> Your two cases suggest to me that a NAT64 should never see
>>>>          
>> such packets.
>>      
>>>> If it is in the same box as a 6-in-4 tunnel endpoint the
>>>>          
>> decapsulation
>>      
>>>> should have happened already and if the packet is just
>>>>          
>> passing through
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Mar 2010 01:47:37 +1300

OK for me.

Regards
   Brian Carpenter

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 30 Mar 2010 09:12:21 -0700

> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Tuesday, March 30, 2010 1:08 AM
> To: Dan Wing
> Cc: 'Behave WG'; 'David Harrington'; 'Behave Chairs'

If you highlight protocol 41 as "SHOULD drop", you should highlight *why*
you're highlighting protocol 41.  I believe the reasoning 6to4 and 6rd use
protocol 41, and those are tunnel-based IPv6 transition mechanisms that should
not exist in conjunction with 6/4 translation.  Using that same argument,
should a similar recommendation be made for blocking Teredo's UDP port?

In any event, I would feel more comfortable if this text was put into a
separate paragraph (or subsection) including a quick discussion of the harm of
using those tunnels over the translator, and why blocking them is recommended.

-d

> >>>>>> Protocol 41 inside an IPv4 packet. Maybe that's 
> already discussed
> >>>>>> elsewhere?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>              
> >>>>> no, afaict

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Mar 2010 21:40:43 +0200

El 30/03/10 18:12, Dan Wing escribió:
> you're highlighting protocol 41.
i was not highlighting protocol 41.
I have changed the MUST discard packet form protocols other than 
TCP/UDP/ICMP to SHOULD drop, as i understand this was not only about 
proto 41, but also about Joel's concern about boxes supporting other 
protocols that have not been specified yet.

Do you think somehting else is needed?

>    I believe the reasoning 6to4 and 6rd use
I didn't thought this was needed, but i would be glad to add any text 
anybody can come up with in this regard :-)

Regards, marcelo

>>>>>> it seems like a misconfiguration. So maybe this is a
>>>>>>              
>> SHOULD discard
>>      
>>>>> I was using MUST cause that is what we agreed in the
>>>>>            
>> meeting, but if
>>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 30 Mar 2010 13:57:49 -0700

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Tuesday, March 30, 2010 12:41 PM
> To: Dan Wing

That sounds fine.

-d