From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Mon Jun 30 2003 - 12:40:40 GMT-3
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.
So, reaction TCP and non-TCP is different.
Is it host/vendor depended or RFC ?
> -----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