Re: ICMP Query!!!

From: Andrey Tarasov <andyvt_at_gmail.com>
Date: Sun, 14 Nov 2010 18:45:30 -0800

When you find yourself in the hole, best action is to stop digging :-)

Here is the question for you - you have network with two hosts connected
via two routers. Link between routers has MTU lower than links to hosts.
Path MTU discovery is enabled on the hosts. ICMP is disabled, since it's
not necessary to run the network. Will you be able to transmit a file
larger than host's MTU between the hosts without changing transit packets?

Now, even if we have perfect network where fragmentation is not an
issue, what's about IRDP?

Andrey.

On 11/14/2010 5:45 PM, Tyson Scott wrote:
> This is my last comment, I agree with Marko and Paul, end of my part of
> this discussion.
>
> What is MSS for? What is windowing for? The whole goal of the network is
> to provide the best performance of traffic thru it right?
>
> The Transmission Control Protocol (TCP) receive window size is the maximum
> amount of received data, in bytes, that can be buffered at one time on the
> receiving side of a connection. The sending host can send only that amount
> of data before waiting for an acknowledgment and window update from the
> receiving host. The first part of a TCP handshake is a 3 way connection
> that will include the MSS in the SYN packet to let the sender and receiver
> know the others MSS to help determine how they should calculate their window
> scaling. Matching the receive window to even increments of the MSS
> increases the percentage of full-sized TCP segments used during bulk data
> transmission and thus helps minimize the number of segments sent when large
> sets of data are transmitted.
>
> The size of MSS determines the calculation of the number of packets that can
> be received before acknowledgement in a given window. So the adjustment of
> MSS in the SYN packet between two hosts helps to make sure that the window
> scaling factor calculation between two hosts is providing the best
> performance it can on a high speed network.
>
> I didn't say ip tcp mss adjusts the MSS in a SYN packet during the three way
> handshake as that is already inferred in the command. Helping with
> calculating windowing is an end result of knowing the MSS.
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Andrey Tarasov
> Sent: Sunday, November 14, 2010 5:46 PM
> To: ccielab_at_groupstudy.com
> Subject: Re: ICMP Query!!!
>
> It wasn't my intent to get into offline discussion, so I'm replying back
> to GC. Sorry about that.
>
> I'm not sure how "ip tcp-mss adjust" helps with TCP windowing. My
> understanding that all it does is it sets MSS option in SYN packet to
> specified value. Feature guide for this command hints on the reason for
> it's introduction - PPPoE on DSL links and broken Path MTU Discovery due
> to disabled ICMP on other side of TCP connection.
>
> http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ft_admss.html
> http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00
> 800d6979.shtml
>
> Andrey.
>
> On 11/14/2010 1:47 PM, Tyson Scott wrote:
>> ip tcp mss doesn't use ICMP though, it wasn't added to fix path MTU
>> discovery it was added to fix TCP windowing adjustments, if either the
>> client or server don't supporting the windowing functions. It is to allow
>> the router to listen to and intercept TCP windowing, again not acting as a
>> function of ICMP.
>>
>> I am not here to prove my point, I am discussing my stuff based on
>> information I have received from Cisco, I hold Yusuf Bhaji as a pretty
> good
>> authoritative source on this information. The list is coming from this
> only
>> from a routing perspective but I am discussing it based on both Security
> and
>> Routing. If I am proven wrong in the end, hey we are all the wiser
> because
>> of it.
>>
>> Regards,
>>
>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>> Mailto: tscott_at_ipexpert.com
>> Telephone: +1.810.326.1444, ext. 208
>> Live Assistance, Please visit: www.ipexpert.com/chat
>> eFax: +1.810.454.0130
>>
>> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
>> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
>> CCIE (R&S, Voice, Security& Service Provider) certification(s) with
>> training locations throughout the United States, Europe, South Asia and
>> Australia. Be sure to visit our online communities at
>> www.ipexpert.com/communities and our public website at www.ipexpert.com
>>
>>
>> -----Original Message-----
>> From: Andrey Tarasov [mailto:andyvt_at_gmail.com]
>> Sent: Sunday, November 14, 2010 3:59 PM
>> To: Tyson Scott
>> Subject: Re: ICMP Query!!!
>>
>> I just find your statement "As a network can fundamentally function
>> without the use of ICMP anywhere, meaning I could block all ICMP traffic
>> and everything will still work, I consider it to be out of scope." a tad
>> too strong. And your reply is pretty ironic, given the reason "ip
>> tcp-mss adjust" got added to IOS.
>>
>> On 11/14/2010 12:45 PM, Tyson Scott wrote:
>>> Andrey,
>>>
>>> I am not sure what you mean by me forgetting it. I gave a few examples,
>> by
>>> no means is this an exhaustive discussion of ICMP types but MTU discovery
>>> still relies on unreachable, fragmentation needed, which is still not
>>> necessary. I can still block all ICMP traffic and not cause problems
> with
>>> TCP sessions by setting the "ip tcp mss" on interfaces as well. But I am
>>> not sure if this is what you are referring to?
>>>
>>> Regards,
>>>
>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>> Mailto: tscott_at_ipexpert.com
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>> Andrey Tarasov
>>> Sent: Sunday, November 14, 2010 3:15 PM
>>> To: ccielab_at_groupstudy.com
>>> Subject: Re: ICMP Query!!!
>>>
>>> Tyson,
>>>
>>> I think you forgot Path MTU discovery.
>>>
>>> Regards,
>>> Andrey.
>>>
>>> On 11/14/2010 12:05 PM, Tyson Scott wrote:
>>>> Dale,
>>>>
>>>> I agree. My PAK argument doesn't hold water after I think about it
>>> further
>>>> as well ;). I have thought a lot about this the last day and I think
>>> there
>>>> is room for debate each way. But if you read Yusuf Bhaji's Network
>>> Security
>>>> Technologies book his simple statement on control plane is that it
>>> consists
>>>> of protocols that help to "glue the network together". As a network can
>>>> fundamentally function without the use of ICMP anywhere, meaning I could
>>>> block all ICMP traffic and everything will still work, I consider it to
>> be
>>>> out of scope. That although ICMP traffic may come to the control plane
>>> for
>>>> one reason or another, like ICMP redirect to give better route
>> information
>>>> or ICMP unreachable in the event of an unknown network or TTL expiration
>>> for
>>>> traceroute, ICMP is not required to run the network. Whereas other
>> things
>>>> like IGMP, as Paul pointed out below is required for multicast to work.
>>>>
>>>> Fundamentally the Control Plane is traffic generated or accepted by the
>>>> router that are necessary for the network to perform functions, i.e.
>>> routing
>>>> protocols, multicast, IOS firewall (transit control plane). ICMP
> doesn't
>>>> fall under any of those categories. Read Yusuf's book, it is probably
>> one
>>>> of the best clarifications on this topic out there. I also have the
>>> slides
>>>> from his internal presentation on the topic.
>>>>
>>>> Now in what I have stated I will clarify that ICMP should be considered
>> in
>>>> CoPP Policy because it is a protocol that can affect the performance and
>>>> security of the router. Just as undesirable traffic is also considered
>>>> something you should protect the control plane from or undesirable IP
>>>> options. So ICMP falls under the category of a protocol that Control
>>> Plane
>>>> Protection is used to prevent from affecting the router not a protocol
>>> that
>>>> is necessary for the operation of the control plane.
>>>>
>>>> Regards,
>>>>
>>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>>> Mailto: tscott_at_ipexpert.com
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Nov 14 2010 - 18:45:30 ART

This archive was generated by hypermail 2.2.0 : Sun Dec 05 2010 - 22:14:56 ART