From: Andrew Caslow (abcaslow@netmasterclass.net)
Date: Fri Jun 11 2004 - 13:37:47 GMT-3
Ken,
As you mentioned, traceroute uses UDP packets when it generates the
traceroute probe packets. These UDP packets originate from the device
that executed the traceroute command. Yes, traceroute uses UDP; however
the whole purpose of traceroute is to generate ICMP messages from
transit IP devices between the source (transit devices such as routers)
and the ultimate target of the traceroute. These traceroute generated
ICMP messages allow you to see the specific path to a given destination.
Traceroute depends on the common router practice of sending an ICMP Time
Exceeded message to the source when a traceroute generated packet
attains the TTL value of 0. This is in conformance to RFC 1812 (The
Router Requirements RFC) Section 5.3.1 Time to Live (TTL). This section
states:
" If the TTL is reduced to zero (or less), the packet MUST be discarded,
and if the destination is not a multicast address the router MUST send
an ICMP Time Exceeded message to the source."
So, a traceroute traffic pattern consists of: outbound UDP traffic and
return path ICMP traffic. A traceroute traffic pattern does not consist
of outbound ICMP traffic and inbound UDP traffic.
Here is some sample output. For the following traceroute:
r1#traceroute 172.16.35.5
Type escape sequence to abort.
Tracing the route to 172.16.35.5
1 172.16.123.3 12 msec 12 msec 12 msec
2 172.16.35.5 12 msec * 12 msec
The following debug was generated:
IP: s=172.16.123.1 (local), d=172.16.35.5 (Serial0/0.123), len 28,
sending
UDP src=33377, dst=33434
IP: s=172.16.123.3 (Serial0/0.123), d=172.16.123.1 (Serial0/0.123), len
56, rcvd 3
ICMP type=11, code=0
IP: s=172.16.123.1 (local), d=172.16.35.5 (Serial0/0.123), len 28,
sending
UDP src=33251, dst=33436
IP: s=172.16.123.1 (local), d=172.16.35.5 (Serial0/0.123), len 28,
sending
UDP src=34293, dst=33437
IP: s=172.16.35.5 (Serial0/0.123), d=172.16.123.1 (Serial0/0.123), len
56, rcvd 3
ICMP type=3, code=3
Notice that all of the sent packets were UDP and all of the received
packets are ICMP. In particular, two types of ICMP messages were
received:
ICMP Type 11 Code 0 (Time Exceeded)
ICMP Type 3 Code 3 (Port Unreachable)
The ICMP "Time Exceeded" messages are generated by the routers in the
path taken by the traceroute probe.
The ICMP "Port Unreachable" message is generated by the target
traceroute device.
For Cisco access-lists, the ACL keyword to match on ICMP time exceeded
messages is "time-exceeded". For ICMP port unreachable messages, the IOS
gives you two options "port-unreachable" and "unreachable". The first
ACL keyword is for only ICMP "port-unreachable messages" the second
keyword is for all ICMP "unreachable" messages.
See the following site for all ICMP message types:
http://www.iana.org/assignments/icmp-parameters
Therefore, when you encounter a configuration requirement that instructs
you to block traceroute traffic, carefully consider whether the
requirement is for blocking outbound traceroute traffic, this is UDP
traffic only, or is it return-path traceroute traffic, this is ICMP
traffic only.
For more details on how traceroute works, take a look that the following
NetMasterClass Tech-Note at http://www.netmasterclass.net/site/lib.php
"Debugging Techniques with Traceroute"
HTH,
-Bruce Caslow CCIE #3139
NetMasterClass, LLC
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Kenneth Wygand
Sent: Friday, June 11, 2004 10:31 AM
To: Brian McGahan; ccie2be; Group Study
Subject: RE: icmp filtering
Figure that out. Cisco traceroute uses UDP, yet it's matched in an ACL
as "permit _icmp_ any any time-exceeded" and "permit _icmp_ any any
unreachable".
Is it even possible to match traceroutes with a "permit udp" command?
Kenneth E. Wygand
Systems Engineer, Project Services
CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
Network+, A+
Custom Computer Specialists, Inc.
"The only unattainable goal is the one not attempted."
-Anonymous
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Tuesday, June 08, 2004 7:18 PM
To: ccie2be; Group Study
Subject: RE: icmp filtering
> ***************
> Since a traceroute uses ping, and the icmp message type isn't
considered
> since all messages types are allowed, wouldn't any type of icmp
message
> type
> be allowed back in by virtue of the "permit icmp any any reflect ICMP"
and
> therefore negate the need for explicitly allowing
> the icmp time-exceeded and unreachable message types?
>
> **********************
Cisco traceroute doesn't use ICMP, it uses UDP. Read Lab 3 task 10.1 -
10.3 breakdown for more info.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, June 08, 2004 6:07 PM
> To: Brian McGahan; Group Study
> Subject: Re: icmp filtering
>
> Thanks for getting back to me.
>
> See comments in-line.
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study"
<ccielab@groupstudy.com>
> Sent: Tuesday, June 08, 2004 6:02 PM
> Subject: RE: icmp filtering
>
>
> Tim,
>
> What about the question and solution implies this? The question
> says:
>
> "Configure your network so that ICMP traffic is only allowed into your
> network if the traffic was initiated from behind R5. For diagnostic
and
> troubleshooting purposes, ensure that users throughout your network
are
> still able to traceroute from behind R5."
>
> The solution is:
>
> R5:
> interface Ethernet0/1
> ip access-group DENY_SNMP in
> ip access-group EVALUATE_ICMP out
> !
> ip access-list extended DENY_SNMP
> deny udp any any eq snmp
> permit icmp any any time-exceeded
> permit icmp any any unreachable
> evaluate ICMP
> deny icmp any any
> permit ip any any
> !
> ip access-list extended EVALUATE_ICMP
> permit icmp any any reflect ICMP
> permit ip any any
>
> Essentially you are watching ICMP traffic that is exiting:
>
> permit icmp any any reflect ICMP
>
> and you are allowing it back in only if was initiated from the
> inside:
>
> evaluate ICMP
> deny icmp any any
>
> ***************
> Since a traceroute uses ping, and the icmp message type isn't
considered
> since all messages types are allowed, wouldn't any type of icmp
message
> type
> be allowed back in by virtue of the "permit icmp any any reflect ICMP"
and
> therefore negate the need for explicitly allowing
> the icmp time-exceeded and unreachable message types?
>
> **********************
>
> but you are allowing trace replies back:
>
> permit icmp any any time-exceeded
> permit icmp any any unreachable
>
> How does this relate to echo or echo-reply?
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > ccie2be
> > Sent: Tuesday, June 08, 2004 4:40 PM
> > To: Group Study
> > Subject: icmp filtering
> >
> > Hi guys,
> >
> > I hope this isn't too dumb a question, but...
> >
> > Can someone confirm what this acl entry does?
> >
> > ip access-list ext ping
> > permit (or deny) icmp any any <-----
> >
> > In particular, does this allow all icmp message types or just
> echo-request
> > and
> > echo-reply?
> >
> > I've search the Doc Cd and the whole of cisco.com but couldn't find
> > anything
> > definative.
> >
> > I would think it would allow ( or deny) all icmp message types but,
> I'm
> > doing
> > practice IE lab 2, task 10.8 - 10.10 and the solution seems to
> indicate
> > that
> > it only permits message types echo-request and echo-reply.
> >
> > Any feedback would be appreciated. Also, if someone knows of any
> links
> > which
> > discusses in detail, please let me know.
> >
> > TIA, Tim
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:38 GMT-3