From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon Jun 30 2003 - 12:04:57 GMT-3
I'm concerned this thread is starting to mix several different
concepts. MTU path discovery, defined in RFC 1191, is totally an IP
function. It should be done at the initialization of a host
interface, and in no way depends on TCP or UDP.
At 11:46 AM +0800 6/30/03, sohu wrote:
>Hello
> I know that the host shall negotiate with the peer the MSS value
>by TCP SYN option.when the host receives icmp 3 4,the tcp conncetion
>shall automaticlly adjust its MSS to the value the ICMP gave.
You've described one mode of TCP operation, which is an exception
case that might be encountered if the path changes significantly
after session start. Normally, a reasonable TCP implementation would
initialize after MTU discovery, and set its MSS appropriately. MSS
and MTU are not synonymous. There are certainly performance
characteristics in which MSS might be greater than MTU -- TCP doesn't
really care because it's dealing with a byte stream.
>Because only tcp protocol shall reponse to ICMP 3 4 ,I have a little
>confusion about how UDP or IP to adjust theire sending MTU ?
If you are using path discovery, IP should have changed the MTU long
before TCP started. If you get ICMP 3 4 after the session starts, it
really depends on the implementation of both TCP and IP as to whether
receiving this ICMP response will or will not affect the MTU.
Adjusting the MSS is independent.
> For example:
> h1(MTU 1500)---r1(MTU1400)---r2--(MTU1500)host2
> if I issue ping -s 1500 to the destination to h2 with DF bit
>=1.When the packet reaches r1,the r1 shall drop this packet becasue
>the MTU value is 1400 and the packet DF=1 set.The R1 shall send icmp
>3 4 with recommend mtu=1400 to the source of the packet which is
>h1.If the h1 can not adjust the sending MTU,so the ping can not
>succeed any time.Wheather this statement is true ??
But you _want_ the ping to fail under these conditions. You've
described a situation in which data is not going to be able to pass
from H1 to H2 unless something gets adjusted, and lots of software
isn't designed to do that. The ping failure should report the ICMP
message, and it's then a troubleshooting matter. A practical way
might be to bounce the H1 interface and let it rediscover path MTU.
I'm really not sure what you are trying to do by explicitly setting
DF on a ping, and, specifically, a ping of unusual length. I can't
see any useful purpose other than trying to troubleshoot a MTU
restriction that can't be resolved by path discovery. Indeed, there
is an exploit called the "ping of death" that will crash some
machines by sending ping with very long data fields -- not something
you want to do routinely.
If you didn't set DF in your example, the ping would work because R1
would fragment -- totally correct behavior.
>----- Original Message -----
>From: "Volkov, Dmitry (IDS Canada)" <dmitry_volkov@ca.ml.com>
>To: "'Howard C. Berkowitz'" <hcb@gettcomm.com>; <ccielab@groupstudy.com>
>Cc: <security@groupstudy.com>
>Sent: Monday, June 30, 2003 6:58 AM
>Subject: RE: reaction on ICMP 3 4
>
>
>> I was blind new next Hop MTU is inside ICMP 3 4:
>>
>> 7 and 8 th bytes of ICMP header.
>>
>> To support the Path MTU Discovery
>> technique specified in this memo, the router MUST include the MTU of
>> that next-hop network in the low-order 16 bits of the ICMP header
>> field that is labelled "unused" in the ICMP specification [7]. The
>> high-order 16 bits remain unused, and MUST be set to zero.
>> http://www.ietf.org/rfc/rfc1191.txt
>>
>> http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00
>> 800d6979.shtml#second
>>
>> Thanks, Howard.
>>
>> Dmitry
>>
>> > -----Original Message-----
>> > From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>> > Sent: Sunday, June 29, 2003 5:34 PM
>> > To: ccielab@groupstudy.com
>> > Cc: 'security@groupstudy.com'
>> > Subject: Re: reaction on ICMP 3 4
>> >
>> >
>> > At 5:09 PM -0400 6/29/03, Volkov, Dmitry (IDS Canada) wrote:
>> > >How TCP/IP stack reacts on receiving ICMP type 3 code 4
> > > Fragmentation needed
>> > >but DF set ?
>> > >I mean how many bytes will be sent next time after receiving ICMP
>> > >unreachable.
>> > >I lowered IP mtu to 1420 and router sent ICMP and host
>> > started send 1420 !!
>> > >I sniffed ICMP packed and I didn't see anything inside ICMP
>> > indicating
>> > >allowable MTU.
>> > >How source knows what size frame to retransmit ?
>> > >
>> >
>> > More information is needed to answer this. Is the host actively
>> > participating in MTU autodiscovery, or is it just setting DF? There
>> > are valid reasons for the latter. For example, the old IBM RSRB
>> > method of Fast Sequenced Transport sets DF, and then steals the
>> > fragmentation fields in the header for IBM information.
>> >
> > > In any case, this is going to be a host implementation matter.
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:14 GMT-3