Re: Path MTU Discovery
Dan.McDonald@eng.sun.com (Dan McDonald) Fri, 07 February 1997 07:23 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA17154 for ipsec-outgoing; Fri, 7 Feb 1997 02:23:17 -0500 (EST)
From: Dan.McDonald@eng.sun.com
Message-Id: <199702070727.XAA24969@kebe.eng.sun.com>
Subject: Re: Path MTU Discovery
To: angelos@aurora.cis.upenn.edu
Date: Thu, 06 Feb 1997 23:27:27 -0800
Cc: ipsec@tis.com
In-Reply-To: <9702070346.AA07074@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 6, 97 10:46:01 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> > > >An encrypting router often has a "tunnel interface" that'll have properties > >like: > > > > tun0: 10.69.0.0/16 --> 10.9.1.25 > > Not necessarilly. Virtual interfaces might not be used, or you might > have more than one SPIs using the same interface. Per SPI(-chain) MTUs > need to be kept. If you have a router that behaves as you describe, > then you don't need any other provision. Hmmm. In a router-to-host tunneling case, you MIGHT be right. Let's consider one other property about router-to-* tunneling. Since the router is the _originator_ of the outermost packet, it does not need to obey the inner packet's "Don't fragment" bit. Remember, I'm originating the packet. There's one faulty assumption you make below. I'll point it out in a bit. This may explain why we aren't agreeing here. > Which is the same as keeping that information on a per-SPI(-chain) > basis, if you don't use ViFs. Could you illustrate a non-VIF case? Granted, in the NRL code, there's an "encrypting route," but even there, I just don't see any of the MTU problems. > Another point is that fragmentation checking should be done before any > IPsec handling takes place (easier and faster). WRONG FOR OUTBOUND PACKETS!!! This is in clear violation of RFC 1825. Lemme quote: >> 3.1 AUTHENTICATION HEADER <SNIP!> >> Fragmentation occurs after the Authentication Header processing for >> outbound packets and prior to Authentication Header processing for >> inbound packets. The receiver verifies the correctness of the There actually isn't text in the ESP section, but I'll bet small sums that either Ran A. or Steve K. will back me up on this one. If you meant inbound packets, my bad. > Only if you can associate a packet "flow" with the ICMP message; easy > to do if you use a ViF for each tunnel. Any implementors out there not doing this? I can only see this in the router-to-host tunnel. > So TCP has to "forsee" whether a packet will go through IPsec, and if > so what will be the size overhead. It'll know. Before that SYN or SYN/ACK gets sent, it can consult endpoint state (socket, pcb, whatever) and make an appropriate guess. Dan
- Path MTU Discovery Angelos D. Keromytis
- RE: Path MTU Discovery Sanjay Anand
- RE: Path MTU Discovery Stephen Kent
- Re: Path MTU Discovery Dan McDonald
- Re: Path MTU Discovery Dan McDonald
- Re: Path MTU Discovery Angelos D. Keromytis
- Re: Path MTU Discovery Angelos D. Keromytis
- Re: Path MTU Discovery Craig Metz
- Re: Path MTU Discovery Ran Atkinson
- Re: Path MTU Discovery Dan McDonald
- Re: Path MTU Discovery Angelos D. Keromytis
- Re: Path MTU Discovery Ben Rogers
- Re: Path MTU Discovery Oliver Spatscheck
- Re: Path MTU Discovery Ran Atkinson
- Re: Path MTU Discovery Ran Atkinson
- Re: Path MTU Discovery Angelos D. Keromytis
- Re[2]: Path MTU Discovery Whelan, Bill