Subject: Re: [dnsext] What ELSE relies on UDP fragmentation?

From: Nicholas Weaver <[email-masked]>
Date: Wed, 19 Aug 2009 13:38:49 -0700

On Aug 19, 2009, at 11:20 AM, Dean Anderson wrote:
>>
>> Because people are realizing in the DNSSEC community (like IKE did)
>> that you can't rely on UDP fragmentation to work in a non-trivial  
>> (~10%
>> +) of the cases when we actually measure things.
>
> I was unaware that IKE was having problems with UDP fragmentation. IKE
> is a widely deployed protocol.  Is there some documentation of this
> claim?

 From this very thread:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02069.html

 From the referred RFC 3723 section 5.6:

>   When certificate authentication is used, IKE fragmentation can be
>   encountered.  This can occur when certificate chains are used, or
>   even when exchanging a single certificate if the key size or size of
>   other certificate fields (such as the distinguished name and other
>   OIDs) is large enough.  Many Network Address Translators (NATs) and
>   firewalls do not handle fragments properly, dropping them on inbound
>   and/or outbound.
>
>   Routers in the path will also frequently discard fragments after the
>   initial one, since they typically will not contain full IP headers
>   that can be compared against an Access List.
>
>   As a result, where IKE fragmentation occurs, the endpoints will  
> often
>   be unable to establish an IPsec security association.  The solution
>   to this problem is to install NAT, firewall or router code load that
>   can properly support fragments. If this cannot be done, then the
>   following alternatives can be considered:
>
>   [1]  Obtaining certificates by other means.
>
>   [2]  Reducing the size of the certificate chain.
>
>   [3]  Reducing  the size of fields within the certificates.  This
>        includes reduction in the key size, the distinguished name or
>        other fields.  This should be considered only as a last resort.
>

Google for IKE fragmentation, and you get (on page 1)::

The CISCO IKE fragmentation extension:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_fragment_ike_pack.html

> Fragmentation of IKE Packets
> First Published: September 12, 2008
> Last Updated: September 19, 2008
> Some third-party vendor devices, such as firewalls configured for  
> stateful packet inspection, do not permit the passthrough of User  
> Datagram Protocol (UDP) fragments in case they are part of a  
> fragmentation attack. If all fragments are not passed through,  
> Internet Key Exchange (IKE) negotiation fails because the intended  
> responder for the virtual private network (VPN) tunnel cannot  
> reconstruct the IKE packet and proceed with establishment of the  
> tunnel.
>
> This feature provides for the fragmentation of large IKE packets  
> into a series of smaller IKE packets to avoid fragmentation at the  
> UDP layer (for example, for large certificate payloads or  
> certificate request payloads).
>
> This feature provides support for Cisco IOS in terms of being a  
> responder in an IKE main mode exchange.
>

The MSDN synopsys of IKE for Windows Server Protocols:

http://msdn.microsoft.com/en-us/library/cc233458%28PROT.13%29.aspx

> 1.3.2 IKE Fragmentation
>
> IKE uses UDP as a transport. IKE messages can be sufficiently large;  
> so the underlying IP layer may fragment them, as described in  
> [RFC791] section 2.3. This fragmentation typically happens with IKE  
> messages that contain certificate chains. To avoid fragmentation- 
> based attacks, fragmented UDP packets are commonly blocked by  
> firewalls and routers. Blocking the fragmented UDP packets can lead  
> to IKE failures that are especially difficult to diagnose. The IKE  
> fragmentation extension that is specified in this document avoids  
> fragmentation at the IP level by fragmenting IKE packets into  
> smaller UDP packets that the underlying IP layer is guaranteed not  
> to fragment.
>
> Hosts that support IKE fragmentation advertise this capability  
> through a "FRAGMENTATION" vendor ID payload; for more information,  
> see section 1.7. If both peers support fragmentation, a  
> fragmentation timer is started whenever a message is sent. If the  
> timer expires, it is assumed that the message that is associated  
> with the timer did not reach its destination because it was too  
> large to traverse the intervening network. In this case, the message  
> is split into several small fragments, and all these small fragments  
> are sent.
>
> So that the destination host can correctly reassemble the fragmented  
> message, each fragment carries a fragment ID that is unique to the  
> original message and a fragment number that is unique to the  
> particular fragment. Fragment numbers range from 1 to N, where N is  
> the number of fragments for a message.
>
> Upon receipt of a fragment, the receiving host verifies whether it  
> has already received other fragments for that fragment ID. If not,  
> the receiving host starts a reassembly timer. It then verifies  
> whether it has received all N fragments for the message, where the  
> Nth fragment is indicated by a particular bit in the fragment. If  
> the fragment reassembly timer expires before all fragments are  
> correctly received, the receiving host must discard all fragments.
>
> For details, see section 3.3.
>

How is this not specifically IKE having problems with fragmentation,  
such that multiple vendors have written extensions to do application- 
level fragmentation and that RFCs themselves give recommendations on  
shrinking certificates to avoid fragmentation?

Likewise, experience with using RADIUS on wide scale, which also  
relies on fragmentation:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02099.html

>> EG, a very simple firewall rule:
>> DENY all
>> ALLOW udp 53
>> ...
>>
>> has the effect of, if the firewall is not stateful for fragments, of
>> killing fragmented traffic.
>
> Well, There are a number of very simple configuration command can also
> do some bad things:
>
>  Erase flash:
>  reload
>
> That people _can_ do something stupid like configure a firewall to  
> drop
> fragments is no reason to not allow fragmentation.  In other words:
> "Your misunderstanding of the protocol does not alter the protocol."

But it may very well be so if the misunderstanding is there first:

an example from Paul Vixie on Bind:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02088.html

Likewise, how many broken IE-isms have corrupted the web?  The first  
adopters, and the widespread adopters, define the real standards.

Its an ugly situation, and believe me, I don't like it very much, but  
simply saying "its broken" and "Its nonstandard" and "those who are  
broken should fix things" doesn't help if and when the brokenness is  
widespread.

>> Yet at the same time, the Internet has developed a couple of default
>> MTUs that, if you assume them, do work, without MTU path discovery.
>
> In fact, "The Internet"  has not actually developed any default MTUs,
> mostly because "The Internet" is a fictional entity.  By contrast,
> RFC791 states on page 25:
>
> Every internet module must be able to forward a datagram of 68 octets
> without further fragmentation. This is because an internet header may
> be up to 60 octets, and the minimum fragment is 8 octets.
>
> I am always amused when people invent fictional authorities like "The
> Internet" to justify their unjustifiable claims.

If you prefer:  The practical default MTU ceiling of 1500B applies for  
a substantial majority of hosts connected to this wide area network-of- 
networks colloquially called the Internet, as a side consequence of  
these hosts being connected through a layer 2 media which is somehow  
known as "Ethernet" which uses an 802.3 or related data framing.

There may be lower MTUs on portions of the network (e.g. the 1492 of  
PPPoE, the 576 of many dialup connections), but I seriously doubt  
there are many paths between two hosts on the group of networks  
colloquially called the Internet where the MTU is greater than 1500.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Aug 2009 21:12:21 +0000

nick, please do not feed the trolls.  --paul

re:

> Cc: "[email-masked] WG" <[email-masked]>,
>         Nicholas Weaver <[email-masked]>
> From: Nicholas Weaver <[email-masked]>
> To: Dean Anderson <[email-masked]>
> Subject: Re: [dnsext] What ELSE relies on UDP fragmentation?
> Date: Wed, 19 Aug 2009 13:38:49 -0700
> X-Mailer: Apple Mail (2.936)
> Sender: [email-masked]
> 
> 
> 
> >> that you can't rely on UDP fragmentation to work in a non-trivial  (~10%
> >   As a result, where IKE fragmentation occurs, the endpoints will  often
> > fragmentation attack. If all fragments are not passed through,  Internet
> > Key Exchange (IKE) negotiation fails because the intended  responder for
> > the virtual private network (VPN) tunnel cannot  reconstruct the IKE
> > packet and proceed with establishment of the  tunnel.
> >
> > This feature provides for the fragmentation of large IKE packets  into a
> > series of smaller IKE packets to avoid fragmentation at the  UDP layer
> > (for example, for large certificate payloads or  certificate request
> > payloads).
> >
> > IKE uses UDP as a transport. IKE messages can be sufficiently large;  so
> > the underlying IP layer may fragment them, as described in  [RFC791]
> > section 2.3. This fragmentation typically happens with IKE  messages that
> > contain certificate chains. To avoid fragmentation- 
> > based attacks, fragmented UDP packets are commonly blocked by  firewalls
> > and routers. Blocking the fragmented UDP packets can lead  to IKE
> > failures that are especially difficult to diagnose. The IKE
> > fragmentation at the IP level by fragmenting IKE packets into  smaller
> > UDP packets that the underlying IP layer is guaranteed not  to fragment.
> >
> > Hosts that support IKE fragmentation advertise this capability  through a
> > "FRAGMENTATION" vendor ID payload; for more information,  see section
> > 1.7. If both peers support fragmentation, a  fragmentation timer is
> > started whenever a message is sent. If the  timer expires, it is assumed
> > that the message that is associated  with the timer did not reach its
> > destination because it was too  large to traverse the intervening
> > network. In this case, the message  is split into several small
> > fragments, and all these small fragments  are sent.
> >
> > original message and a fragment number that is unique to the  particular
> > fragment. Fragment numbers range from 1 to N, where N is  the number of
> > fragments for a message.
> >
> > Upon receipt of a fragment, the receiving host verifies whether it  has
> > already received other fragments for that fragment ID. If not,  the
> > receiving host starts a reassembly timer. It then verifies  whether it
> > has received all N fragments for the message, where the  Nth fragment is
> > indicated by a particular bit in the fragment. If  the fragment
> > reassembly timer expires before all fragments are  correctly received,
> > the receiving host must discard all fragments.
> >
> How is this not specifically IKE having problems with fragmentation,  such
> that multiple vendors have written extensions to do application- 
> Likewise, experience with using RADIUS on wide scale, which also  relies on
> fragmentation:
> 
> > That people _can_ do something stupid like configure a firewall to  drop
> simply saying "its broken" and "Its nonstandard" and "those who are  broken
> should fix things" doesn't help if and when the brokenness is  widespread.
> 
> If you prefer:  The practical default MTU ceiling of 1500B applies for  a
> substantial majority of hosts connected to this wide area network-of- 
> networks colloquially called the Internet, as a side consequence of  these
> hosts being connected through a layer 2 media which is somehow  known as
> "Ethernet" which uses an 802.3 or related data framing.
> 
> PPPoE, the 576 of many dialup connections), but I seriously doubt  there
> are many paths between two hosts on the group of networks  colloquially
> called the Internet where the MTU is greater than 1500.
> 
> 
>