[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Fwd: Tunnel MTU

On 2007-09-25 09:33, Templin, Fred L wrote:
Brian, 
-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Sunday, September 23, 2007 4:35 PM 
To: Templin, Fred L
Cc: rrg@psg.com
Subject: Re: [RRG] Fwd: Tunnel MTU

I must confess that I don't like loading up tunnel end-points
with this kind of complexity.


Ideally, the tunnel endpoint (TE) could simply set an MTU
of (64KB - ENCAPS) and admit all packets smaller than that
size. But, that would result in excessive in-the-network
fragmentation and/or silent loss due to path MTU restrictions.
Also, the tunnel must be made capable of passing packets as
large as 1280 bytes (for IPv6) and should be made capable of
passing packets up to 1500 bytes or larger (for all tunnels).


Architecturally, I much prefer
the e2e RFC 4821 approach. That isn't exclusive to TCP.


I agree that the e2e RFC 4821 approach is desireable, but
the tunnel cannot control the e2e use of RFC 4821 and
cannot even detect when RFC4821 is being used. So, the
tunnel has to provide consistent handling of packets
of various sizes independent of RFC821. 

That's where we differ. I'm arguing that the tunnel shouldn't
worry about it. MTU is an e2e problem and we should focus on
solving it e2e. Solving it specifically for tunnels still
leaves the problem open at Internet level.


In fact there's a fairly simple approach to MTU discovery for
UDP based protocols that have any kind of feedback from destination
to source (i.e. start small and increase the packet size until
the far end detects fragmentation or loss). 4821 does discuss this
briefly.


RFC4821 also discusses the use of IP fragmentation as a
packetization layer in Section 10.3.


Yes, but that struck me as ugly.


One could also think about a generic non-ICMP UDP echo process
for PLPMTUD, although that does raise DoS and firewall issues.


AFAICT, a simple mitigation for the DoS issue exists. Also
AFAICT, the firewall issue should not come into play if the
echos are made to look like ordinary tunneled data. Please
let me know if I am missing something.


The UDP port concerned has to be open in the firewall, since the
echo process is playing the role of a server. That's probably
less awkward than getting ICCMP through, but it still means
convincing the corporate or campus security people to allow
the port. I'm sure they'd like to know how the DoS threat is
mitigated...

    Brian



Thanks - Fred
fred.l.templin@boeing.com

Regards
    Brian Carpenter
    University of Auckland


On 2007-09-21 09:50, Templin, Fred L wrote:

(Fwd'd from 'int-area'):
Please see below for a proposal that addresses the MTU issues
for *-in-IPv4 tunnels. It also addresses the multi-mtu subnet
issue, since it does not rely on ICMP "packet too big" messages
from the last-hop router. Elements of the proposal include:

  - trailing "footer" and data as part of encapsulation
  - tiny echo requests wrapped in encapsulation headers
    and trailing padding - used as probes to elicit tiny
    echo replies
  - tunnel endpoint discovers tunnel far end EMTU_R and
    reassemby timeout values in initial probes=20
  - periodic probing to discover the tunnel path MTU,
    plus EMTU_R; reassembly timeout fluctuations
  - inner fragmentation to create inner packets no larger
    than EMTU_R
  - outer fragmentation to create outer packets no larger
    than the tunnel path MTU
  - coservative use of fragmentation to avoid packet loss
    within the tunnel
  - TE drops unfragmentable packets larger than EMTU_R
    and sends ICMP PTB w/o wasting tunnel resources
  - protection against fragment misassociations
  - protection against off-path attacks
  - protection against wrapped ip_id
  - backwards compatibility
  - incremental deployment
  - NAT traversal

Please review and send comments.

Thanks - Fred
fred.l.templin@boeing.com

------_=_NextPart_002_01C7FA2B.91342580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
A New Internet-Draft is available from the on-line 
Internet-Drafts=20

directories.


	Title		: Packetization Layer Path MTU Discovery for=20
                          IP/*/IPv4 Tunnels
	Author(s)	: F. Templin
	Filename	: draft-templin-inetmtu-00.txt
	Pages		: 20
	Date		: 2007-9-18
The nominal Maximum Transmission Unit (MTU) MTU of the 
Internet has
become 1500 bytes, but existing IP/*/IPv4 tunneling 
mechanisms impose
an encapsulation overhead that can reduce the effective 
path MTU to

   smaller values.  Additionally, existing IP/*/IPv4 tunneling
   mechanisms are limited in their ability to discover and utilize
larger MTUs. This document specifies new mechanisms for 
conveying

   packets over IP/*/IPv4 tunnels that address these issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-inetmtu-00.txt

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg





--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg