From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Mon Jun 30 2003 - 19:14:42 GMT-3
> -----Original Message-----
> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
> Sent: Monday, June 30, 2003 5:45 PM
> To: ccielab@groupstudy.com
> Subject: RE: reaction on ICMP 3 4
>
>
> At 4:20 PM -0400 6/30/03, Volkov, Dmitry (IDS Canada) wrote:
> > > -----Original Message-----
> >> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
> >> Sent: Monday, June 30, 2003 2:55 PM
> >> To: ccielab@groupstudy.com
> >> Subject: RE: reaction on ICMP 3 4
> >>
> >>
> >> 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?
> >
> >Howard, the above not from RFC it's from real test.
> >In rfc 1191 said :
> >Normally, the host continues to set DF in all datagrams, so that if
> >the route changes and the new PMTU is lower, it will be
> discovered.
> >TCP is doing exactly like that.
> >
> >I know that RFC is about IP.
>
> For both hosts and routers.
>
> >
> >However ICMP and UDP as far as I noticed have DF=0, It means that
> >routers will defrag packets if necessary. When I did test
> >I generated UDP and ICMP traffic with MTU 1500. I changed DF bit to 1
> >(on the router via policy routing) in the middle of paket way.
> >
> >Upon receiving ICMP 3 4 host lowers packet size but start
> to transmit
> >udp/icmp FRAGMENTS.
> >I did this test just for curiosity. I was thinking that if I
> have tunnel on
> >the way of UDP packets
> >and some host will generate have udp packets - I could tell
> sorce to change
> >IP MTU
> >(by means changing DF bit and generating icmp back) to avoid
> fragmentation
> >burden on routers.
> >However in reality I'm not sure - what does put more burden
> on router -
> >changing DF via policy routing or defragmentation ...
>
> I'm not clear where you are going. First, fragmentation puts lots of
> burden on the router, primarily processor but also memory, and also
> (depending on platform) on the forwarding path.
>
> The router should never change DF. It should respond with ICMP when
> there is a violation.
Hmm, Maybe I missed something but as I said hosts send UDP/ICMP witth DF=0
(I look via Sniffer and don't see opposite)
("may fragment") It's why router in the middle doesn't respond with ICMP if
packet "too big" but is doing
defrag itself. It's why I changed DF bit on router to activate ICMP back and
to avoid defrag on routers
However host after it received icmp changed size properly but sending
fragments
However everything is fine with TCP (host sending DF=1)
and PMTUD mechanism works fine
> If the host is implemented reasonably, when it gets a fragmentation
> failed, it should auto-adjust the MTU, perhaps a couple of times
> until it stops getting ICMP 3 4. No burden on the router besides a
> few ICMPs.
Host, for UDP traffic, changes MTU properly but sending fragmets.
No burden on routers but I don't understand why host fragments every paket
assuming I send 1500 bytes
into 2 fragments and continues to send it.
Actually I used Lan traffic generator www.zti-telecom.com - to generate TCP
and UDP traffic
I'm wondring maybe here is the reason of such "strange" behavior. Anyway I
sniffed different
real UDP traffic and DF was always 0.
>
> >
> >I don't know if RFC exists explaining that or it's just
> vendor specific.
> >I'm wondering if it's normal behavior. I'm looking for conceptual
> >explanation.
> >
> >Probably because UDP/ICMP packets are "always" (i tested
> with windows only)
> >transmitted with "may fragment" - there is no reason for
> host to participate
> >in PMTU for udp/icmp traffic ?
>
> It's more fundamental than that. Every UDP transmission is a separate
> event and should not depend on previous state in the host. Knowing
> that you received ICMP 3 4 is previous state.
Well, but TCP MSS is "negotiated" only within SYN, SYN-ACK packets
lowest is winner. I think PMTU mechanism doesn't care about stateful nature
of traffic.
UDP has characteristic of flow (source/destin IP, ports) - it's pretty
predictable as well.
So why it wouldn't work, regarding PMTUD, as TCP does. Why packets have DF=0
?
eliminating PMTUD from the scope.
>
> Now, I'll agree that IP is also stateless, but it's a reasonable
> implementation decision to adapt the interface MTU based on ICMP 3 4.
> It wouldn't be scalable to do different MTUs for different paths.
> In a modern network, the MTU shouldn't change frequently. I'll admit
> that if I can't use MTU route discovery, I may be conservative and
> set the MTU to 1472 or less to allow getting through at least one GRE
> tunnel. The GRE header has six mandatory bytes, but can be longer.
>
> >
> >> 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.
> >
> >Exactly that is my point. I was surprising seeing that.
> >
> >> >
> >> >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.
> >
> >Well, UDP stateless but again why to send fragments ;)
>
> I don't understand. Host UDP is stateless. IP decision-to-fragment is
> also stateless.
>
> If the host application wanted to avoid fragmentation, its IP should
> do route discovery, or set a conservative MTU.
>
> >
> >
> >> >
> >> >
> >> >
> >> >> -----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
> >>
> >>
> >> ______________________________________________________________
> >> _________
> >> 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
> >
> >
> >_____________________________________________________________
> __________
> >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
>
>
> ______________________________________________________________
> _________
> 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