From: Daniel Kutchin (daniel@kutchin.com)
Date: Mon Oct 20 2008 - 18:42:49 ARST
Apparently RFC 1393 isn't being implemented. This acl was toothless dog:
ip access-list extended acl-f0/0-in
deny ip any any option traceroute log
deny udp any any option traceroute log
permit ip any any
Daniel
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott M Vermillion
Sent: Montag, 20. Oktober 2008 19:27
To: 'Scott Morris'; ccie820@gmail.com; ccielab@groupstudy.com
Subject: RE: Access list question (WARNING: Ridiculously Long Follow-Up)
Understood!
I just didn't recall from my original R&S prep that the dynamic ACL entries
*appear* to be very generic, permitting all ICMP between the relevant host
pair, yet the actual logic that is implemented seems to include an invisible
'echo-reply' on the end of the permit statement. So if you didn't know or
remember that, you might assume that you could simply ping your destination
first, thereby opening up ICMP in the reflexive ACL, and then successfully
trace to your destination. In fact you can't do that. So I just wanted to
share that little insight...
Cheers,
Scott(1)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Monday, October 20, 2008 11:22 AM
To: 'Scott M Vermillion'; ccie820@gmail.com; ccielab@groupstudy.com
Subject: RE: Access list question (WARNING: Ridiculously Long Follow-Up)
Or just understanding the differences and limitations!
ICMP is not a "state-oriented" protocol suite. Reflexive ACLs were the
FIRST stab at a "stateful" type arrangement in our routers. They aren't
perfect.
They WERE programmed to assume if an ICMP ECHO went out that an ICMP
ECHO-REPLY would come back, but that's the only related-occurrence for ICMP
that was programmed in AFAIK. That's why the traceroute part doesn't work,
because of HOW it works. :)
HTH,
Scott Morris, CCIE4 #4713, JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
Senior CCIE Instructor
smorris@internetworkexpert.com
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
4
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott M Vermillion
Sent: Monday, October 20, 2008 12:36 PM
To: ccie820@gmail.com; ccielab@groupstudy.com
Subject: RE: Access list question (WARNING: Ridiculously Long Follow-Up)
OK all, I reviewed this morning the section of the IE ATC CoD that includes
Brian Dennis on the CLI configuring and testing a reflexive ACL. Nearly
this exact scenario plays out. He pings a destination, shows the dynamic
entry (which is a deceptively generic-looking ICMP permit type of entry),
then attempts to trace that same destination. Until he places a static
entry permitting "time exceeded" and "port unreachable" in the inbound
direction, the trace fails.
So it seems that reflexive ACLs maintain ICMP state to a greater level of
granularity than what you see when issuing 'show ip access-lists'. I would
personally say, then, that this might be (depending on other task language
and whether or not it's acceptable that the outbound traceroute traffic will
still be permitted) the most effective/efficient solution for the task, at
least in an all-Cisco environment...
-----Original Message-----
From: Scott M Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Friday, October 17, 2008 9:05 PM
To: 'ccie820@gmail.com'; 'ccielab@groupstudy.com'
Subject: RE: Access list question (WARNING: Ridiculously Long Follow-Up)
OK, I've yet to see my original post hit the list (although it may have and
I just didn't get a come-back copy - it happens when things bog down like
this) but I'm going to go ahead and follow up anyway (ridiculously longish
but *perhaps* worth your while)...
I wound up doing a little more contemplating, reviewing, and poking around
-- followed by some raw packet capture from my Windows box and then some
playing in my lab. In spite of a lot of BS floating around out on the
Internet, Microsoft (or anyone else for that matter) did *not* ever
implemented ICMP Type Code 30, which is "traceroute." This would have
resulted in some minimal bandwidth conservation (google it if unfamiliar but
interested), yet required too fundament a change to the IP protocol stack to
ever gain any traction. Thus, it seems to have died on the vine. Rather,
MS implemented an incrementing TTL technique just as with Cisco/*nix UDP
traceroute, but simply used ICMP "echo request," "time exceeded," and "echo
reply" vs. the blend of UDP out and ICMP back in (as discussed earlier) as
implemented by the Cisco (etc) folks.
One fundamental difference between an ICMP traceroute implementation and a
UDP implementation that I seem to have not given any thought to earlier was
the fact that, since the ICMP implementation is (obviously) not sending to a
UDP high port, the ICMP message back to the originator is (obviously) not
ICMP "port unreachable" as in the case of a UDP traceroute implementation;
it's simply "echo reply" when the TTL is finally sufficient to reach the
target. As a result, depending on the task language (whether from your
boss, a devious vendor, or an even more devious proctor (gonna pay for that
one someday)), I suppose it's possible that you can't block >ICMP<
traceroute and at the same time allow ping. To be fair, if you blocked
"time exceeded," you'd more or less defeat the purpose of tracing a
destination by rendering the network topology "invisible," but you'd still
ultimately get a response from your end target and I think you'd also get a
reasonable estimate of hop count based on those lines of little asterisks
that result from timeouts.
I got to thinking a bit about reflective ACLs (coincidentally came up in my
R&S review today). In either the case of a ping or trace initiated from
within the inside network, return state would be established for the reply.
In the case of ping, the expected response would simply be "echo reply." In
the case of ICMP traceroute (assuming the target device wasn't immediately
outside of the router with the reflexive ACL in place) the first (and
subsequent up to the penultimate hop nearest the target) expected response
would be "time exceeded," no? I labbed this up and here's the dynamic entry
that resulted:
R1 f0/0 <-------> f0/0 R3 f0/1 <-------> f0/1 R5
10.0.13.0/24 10.0.35.0/24
(The reflexive ACL is on R3 Fa0/1, reflecting outbound traffic from R1
headed towards R5 and obviously evaluating in the opposite direction back
in)
R1#ping 10.0.35.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.35.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/38/44 ms
R3#sh ip access
Extended IP access list INBOUND
10 evaluate REFLECT
20 deny ip any any log
Extended IP access list OUTBOUND
10 permit icmp any any reflect REFLECT
20 permit udp any any reflect REFLECT
30 deny ip any any log
Reflexive IP access list REFLECT
permit icmp host 10.0.35.5 host 10.0.13.1 (10 matches) (time left 282)
So at least at first glance it seems as though reflexive ACLs are not so
intelligent that they drill down to ICMP types and codes and reflect the
opposite of what went out; they appear to broadly open up ICMP between the
relevant IP host pair if the "transaction" is originated from within.
However, it dawned on me that if this was so (in the case of UDP
traceroute), and I simply pinged my target destination before tracing it, I
should get the reflection that I need in order for the ICMP "time exceeded"
(or any other, for that matter) message to get through. I did a little
further testing and here's the what I observed:
(clearing ACL counters and allowing reflexive state to time out beforehand)
R3#sh ip access
Extended IP access list INBOUND
10 evaluate REFLECT
20 deny ip any any log
Extended IP access list OUTBOUND
10 permit icmp any any reflect REFLECT
20 permit udp any any reflect REFLECT
30 deny ip any any log
Reflexive IP access list REFLECT
R1#ping 10.0.35.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.35.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/39/44 ms
R3#sh ip access
Extended IP access list INBOUND
10 evaluate REFLECT
20 deny ip any any log
Extended IP access list OUTBOUND
10 permit icmp any any reflect REFLECT (5 matches)
20 permit udp any any reflect REFLECT
30 deny ip any any log
Reflexive IP access list REFLECT
permit icmp host 10.0.35.5 host 10.0.13.1 (10 matches) (time left 297)
R3#debug ip packet detail
R3(config)#int fa0/0
R3(config-if)#no ip route-cache
R3(config-if)#int fa0/1
R3(config-if)#no ip route-cache
R1#trace 10.0.35.5
Type escape sequence to abort.
Tracing the route to 10.0.35.5
1 10.0.13.3 24 msec 16 msec 16 msec
2 * * *
3 *
R3#
IP: tableid=0, s=10.0.13.3 (local), d=10.0.13.1 (FastEthernet0/0), routed
via RI B
IP: s=10.0.13.3 (local), d=10.0.13.1 (FastEthernet0/0), len 56, sending
ICMP type=11, code=0
IP: tableid=0, s=10.0.13.3 (local), d=10.0.13.1 (FastEthernet0/0), routed
via RI B
IP: s=10.0.13.3 (local), d=10.0.13.1 (FastEthernet0/0), len 56, sending
ICMP type=11, code=0
IP: tableid=0, s=10.0.13.3 (local), d=10.0.13.1 (FastEthernet0/0), routed
via RI B
IP: s=10.0.13.3 (local), d=10.0.13.1 (FastEthernet0/0), len 56, sending
ICMP type=11, code=0
IP: tableid=0, s=10.0.13.1 (FastEthernet0/0), d=10.0.35.5 (FastEthernet0/1),
rou ted via RIB
IP: s=10.0.13.1 (FastEthernet0/0), d=10.0.35.5 R3# (FastEthernet0/1),
g=10.0.35.5, len 28, forward
UDP src=49339, dst=33437
IP: s=10.0.35.5 (FastEthernet0/1), d=10.0.13.1, len 56, access denied
ICMP type=3, code=3
IP: tableid=0, s=10.0.13.1 (FastEthernet0/0), d=10.0.35.5 (FastEthernet0/1),
rou ted via RIB
IP: s=10.0.13.1 (FastEthernet0/0), d=10.0.35.5 (FastEthernet0/1),
g=10.0.35.5, l en 28, forward
UDP src=49340, dst=33438
IP: s=10.0.35.5 (FastEthernet0/1), d=10.0.13.1, len 56, access denied
ICMP type=3, code=3
R3#sh ip access
Extended IP access list INBOUND
10 evaluate REFLECT
20 deny ip any any log (6 matches)
Extended IP access list OUTBOUND
10 permit icmp any any reflect REFLECT (5 matches)
20 permit udp any any reflect REFLECT (6 matches)
30 deny ip any any log
Reflexive IP access list REFLECT
permit udp host 10.0.35.5 eq 33442 host 10.0.13.1 eq 49307 (1 match)
(time left 271)
permit udp host 10.0.35.5 eq 33441 host 10.0.13.1 eq 49306 (1 match)
(time left 268)
permit udp host 10.0.35.5 eq 33440 host 10.0.13.1 eq 49305 (1 match)
(time left 265)
permit udp host 10.0.35.5 eq 33439 host 10.0.13.1 eq 49304 (1 match)
(time left 262)
permit udp host 10.0.35.5 eq 33438 host 10.0.13.1 eq 49303 (1 match)
(time left 259)
permit udp host 10.0.35.5 eq 33437 host 10.0.13.1 eq 49302 (1 match)
(time left 256)
permit icmp host 10.0.35.5 host 10.0.13.1 (10 matches) (time left 195)
So in spite of there being what appears to be a purely generic and wide-open
reflexive entry permitting ICMP from R5 to R1, the "port unreachable"
traffic certainly appears to be getting dropped at R3 fa0/1 (and this
remains the case without that line 20 'deny ip any any log' seen in ACL
"INBOUND" - I put that there simply to validate the hits). Anybody have any
thoughts about this? Am I missing something obvious (or subtle for that
matter) or does the reflexive ACL appear to be acting more intelligent than
it appears?
Obviously curiosity gets the best of me at this point, so I have to replace
R1 with my Windows box. The result:
C:\Users\Scott>ping 10.0.35.5
Pinging 10.0.35.5 with 32 bytes of data:
Reply from 10.0.35.5: bytes=32 time=34ms TTL=254 Reply from 10.0.35.5:
bytes=32 time=30ms TTL=254 Reply from 10.0.35.5: bytes=32 time=23ms TTL=254
Reply from 10.0.35.5: bytes=32 time=23ms TTL=254
Ping statistics for 10.0.35.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round
trip times in milli-seconds:
Minimum = 23ms, Maximum = 34ms, Average = 27ms
C:\Users\Scott>tracert 10.0.35.5
Tracing route to 10.0.35.5 over a maximum of 30 hops
1 6 ms 13 ms 7 ms 10.0.13.3
2 30 ms 30 ms 29 ms 10.0.35.5
Trace complete.
Now I need to add in an extra hop and see if "the cloud" in between is in
fact obscured, as earlier theorized. Topology changes slightly as follows:
Windows <-------> f0/0 R3 f0/1 <-------> f0/1 R5 f0/0 <-------> f0/0
R2
10.0.13.0/24 10.0.35.0/24 10.0.25.0/24
C:\Users\Scott>ping 10.0.25.2
Pinging 10.0.25.2 with 32 bytes of data:
Reply from 10.0.25.2: bytes=32 time=63ms TTL=253 Reply from 10.0.25.2:
bytes=32 time=52ms TTL=253 Reply from 10.0.25.2: bytes=32 time=43ms TTL=253
Reply from 10.0.25.2: bytes=32 time=29ms TTL=253
Ping statistics for 10.0.25.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round
trip times in milli-seconds:
Minimum = 29ms, Maximum = 63ms, Average = 46ms
C:\Users\Scott>tracert 10.0.25.2
Tracing route to 10.0.25.2 over a maximum of 30 hops
1 8 ms 9 ms 9 ms 10.0.13.3
2 * * * Request timed out.
3 42 ms 50 ms 50 ms 10.0.25.2
Trace complete.
So in summary, if we're looking at a scenario of purely UDP traceroute
(which is all that will ever exist in a purely Cisco lab environment! ;~) ),
then the reflexive ACL does appear to solve the task and it cannot be
defeated by simply first kicking off a ping to punch a hole in the INBOUND
ACL. If Windows or the like is thrown into the mix, we have to give the
problem further thought (but damn sure not tonight!).
Having said and posted everything that I just did, in honor of it being
Friday night (by this point) and all, I did crack my first beer a couple of
hours back, so this will all be fun to review for sanity tomorrow (and by
all means feel free in the interim)! ;~)
Regards and g'night all,
Scott
-----Original Message-----
From: Scott M Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Friday, October 17, 2008 2:45 PM
To: 'ccie820@gmail.com'; 'ccielab@groupstudy.com'
Subject: RE: Access list question
A couple of things that might be a good idea to familiarize yourself with:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note091
86a00800a6057.shtml
(this explains *Cisco's* implementation of traceroute, which is not
necessarily the exact implementation you will find in, say, Windows)
Once you understand that, it helps to know all of the ICMP types and codes:
http://www.iana.org/assignments/icmp-parameters
Finally, go to the CLI and look at your options when you do 'deny icmp any
any ?' in an extended ACL
Exactly how you might go about constructing your ACL will depend on what
you're trying to block and in what direction. In other words, is it
sufficient to block "icmp port unreachable" and/or "icmp time exceeded" in
the return path but allow "icmp echo reply?" There's a difference between
_breaking_ traceroute and outright disallowing it from leaving a network
(the latter requiring you to look at both flavors of traceroute and evaluate
whether or not you might wind up breaking something in addition). So on and
so on...
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie820@gmail.com
Sent: Friday, October 17, 2008 1:55 PM
To: ccielab@groupstudy.com
Subject: Access list question
*All,
Is there way to block traceroutes and allow pings ?
Your help will be very much appreciated.
GG
*
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:21 ARST