Subject: Re: [Int-area] ipv4-id-update question on routers setting DF bit

From: Joe Touch <[email-masked]>
Date: Thu, 12 May 2011 15:51:19 -0700

Hi, all,

I sent this note quite a while ago, but got no discussion.

Please send comments soon; I plan to revise the document shortly.

Thanks,

Joe

On 4/1/2011 2:51 AM, Joe Touch wrote:
> Hi, all,
>
> A separate discussion on possible reuse of the ID and frag_offset fields
> (the latter which I hope has been put to rest) raised an issue which the
> current ipv4-id-update doc does not address:
>
> * Can intermediate devices (e.g., routers) set the DF bit?
>
> It's clear they MUST NOT clear the bit (DF=1 -> 0) as this would
> interfere with the purpose of setting the bit.
>
> However, there doesn't appear to be any explicit advice on setting the
> bit (DF=0 -> 1). I'm still digging around for that, and if anyone knows
> more, please post.
>
> Regardless, it seems that setting the bit is even more dangerous,
> because the returning ICMP too-big messages might not arrive at the
> device at the router which sets it, due to legitimate (and even common)
> path asymmetries.
>
> So I'm wondering whether the doc should also include one of the following:
>
> - intermediate devices MUST NOT set the DF bit
>
> - intermediate devices SHOULD NOT set the DF bit
> (this case would require a description of a legitimate case, but
> there does not appear to be any such case which is safe)
>
> Comments would be appreciated.
>
> Joe

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 May 2011 16:44:12 -0700

My first question: do we know of routers that do set DF? Stated in a vacuum, I would generally agree that routers SHOULD or MUST not set it as it changes the implications for the end host (if it is zero, the host is expecting the router to fragment, and may not be able to receive ICMP "too big" messages as you point out), while if it is one, the host is expecting a response. Sounds like an end-2-end violation to me. But -s is this a problem that needs to be solved?

On May 12, 2011, at 3:51 PM, Joe Touch wrote:

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 May 2011 15:10:20 -0400

>> interfere with the purpose of setting the bit.

Actually, clearing the DF flag is common on a number of devices that perform encapsulation / tunneling. This was implemented because of broken pmtud and "inability to browse the internets"  without it.

For example:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftdfipsc.html

and:
"You can include the clear-dont-fragment-bit statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level to clear the Don’t Fragment (DF) bit on all IP version 4 (IPv4) packets entering the IPsec tunnel. If the encapsulated packet size exceeds the tunnel maximum transmission unit (MTU), the packet is fragmented before encapsulation."
https://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/services-configuring-ipsec-service-sets.html

"set flow tcp-mss" (http://kb.juniper.net/InfoCenter/index?page=content&id=KB6346 ) will also cook your noodle.

Operational realities trumping protocol correctness...

W

[Apologies if this has already been discussed, I must have missed it... ]

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 May 2011 12:54:30 -0700

> Operational realities trumping protocol correctness...

Sure, right until that operational reality makes your protocol fail 
because your receiver wasn't capable of reassembling the packet size you 
sent.

Having intermediate devices change these settings interferes with the 
user's intent. When the user was wrong, it helps. When the user was 
right, it hurts.

The frightening part is that managers of intermediate devices think it's 
their decision to make that bet.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 May 2011 13:09:44 -0700

PS, just so we're clear what correct behaviour should be in this case 
for tunnels...

> On 5/13/2011 12:10 PM, Warren Kumari wrote:
...
>> Actually, clearing the DF flag is common on a number of devices that
>> perform encapsulation / tunneling. This was implemented because of
>> broken pmtud and "inability to browse the internets" without it.
>>
>> For example:
>> "You can include the clear-dont-fragment-bit statement at the [edit
>> services service-set service-set-name ipsec-vpn-options] hierarchy
>> level to clear the Don’t Fragment (DF) bit on all IP version 4 (IPv4)
>> packets entering the IPsec tunnel. If the encapsulated packet size
>> exceeds the tunnel maximum transmission unit (MTU), the packet is
>> fragmented before encapsulation."

The appropriate behavior is for the tunnel to clear the DF bit of the 
OUTER header. That way the *tunnel* is responsible for reassembling the 
fragments and passing them along - i.e., the tunnel endpoints clean up 
the work they create.

Clearing the DF bit of packets entering the tunnel is writing a check at 
the tunnel ingress that you expect the end host to cash - i.e., the 
reassembly work is expected at the end host, not the tunnel endpoint. 
Not only is that inappropriate, it can be incorrect if the packet is 
larger than the receiver can reassemble (576 bytes is all that is 
required by RFC 791).

Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 May 2011 16:20:28 -0400

On May 13, 2011, at 3:54 PM, Joe Touch wrote:

> Sure, right until that operational reality makes your protocol fail because your receiver wasn't capable of reassembling the packet size you sent.
> 
> Having intermediate devices change these settings interferes with the user's intent. When the user was wrong, it helps. When the user was right, it hurts.
> 
> The frightening part is that managers of intermediate devices think it's their decision to make that bet.

Oh, this "feature" is also used to clean up other folks broken pmtud -- there is the belief (which luckily is becoming less common, I think) that ICMP is a security threat, and so it should be blocked at the "firewall". If you are trying to talk to a host in one of these networks and need to fragment, you will not be able to deliver the Fragmentation Needed and DF bit set message, and so badness happens. The "obvious" solution here is to just blindly clear DF bits. I mean, everything still works, so it must be fine, right?!

Not sayin' it's right, just that it happens....

W