From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon Jun 30 2003 - 15:54:30 GMT-3
At 11:40 AM -0400 6/30/03, Volkov, Dmitry (IDS Canada) wrote:
>One more question:
>Host supporting MTU path discovery, upon receiving ICMP 3 4, changes segment
>size according to received icmp packet and starts to transmit "normal"
>frames no more that alowed size.
>In case if this host sending UDP or ICMP - with DF=1 - upon receiving ICMP
>3 4 host lowers packet size but start to transmit FRAGMENTS.
Is the above from an RFC? If so, are you sure you aren't confusing
MSS and MTU?
Fragmentation, in the IP RFC and Router Requirements RFC, is
definitely a router function. I've never seen a host actually
fragment, although there are perfectly good reasons for the host to
send DF. I can't picture why a host would put itself through the
overhead of fragmentation, when it can simply reduce MTU and avoid
the situation.
>
>So, reaction TCP and non-TCP is different.
>
>Is it host/vendor depended or RFC ?
If you think about it, it's architectural. TCP is stateful. UDP is
not. For UDP to consider a previous signal, that would mean it is
retaining state.
>
>
>
>> -----Original Message-----
>> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>> Sent: Monday, June 30, 2003 11:05 AM
>> To: ccielab@groupstudy.com
>> Subject: Re: reaction on ICMP 3 4
>>
>>
>> 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.
>>
>>
>> ______________________________________________________________
>> _________
>> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>>
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:15 GMT-3