From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Thu Jul 14 2005 - 16:50:54 GMT-3
Gladston,
As you stated, fragments do not contain any L4 information. So, they
cant match on L4 information. However, IP headers do contain the next
upper layer protocol field (PDU) in the IP header. So, you can specify
the type of IP protocol using the fragments keyword.
When you specify the IP protocol type (number) in the ACE with the
Fragments keyword, the IOS will match and do what you request in that
entry.
IOW,
Access-list 100 deny icmp any any fragments
Access-list 100 permit ip any any
This would deny any non-initial icmp fragment (e.g. FO > 0).
Additionally, this ACE would also permit any initial fragment (e.g. FO =
0); so its not a fragment itself so its not a match. Process to next
entry which is match ip any any. So permit initial fragment or any
other initial fragment or non-fragmented ICMP packet.
At any rate, it's the IP protocol that is defined with the fragments
keyword that takes care of non-initial fragments.
Here's another link for fragments under ACLs:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/
ipras_r/ip1_a1g.htm#wp1078914
HTH,
Andy
-----Original Message-----
From: gladston@br.ibm.com [mailto:gladston@br.ibm.com]
Sent: Thursday, July 14, 2005 11:14 AM
To: ccielab@groupstudy.com
Subject: Fragments
Testing fragment filtering behavior on version 12.1(20)EA1a (cat3550),
it has the following behavior:
If the deny ACE has ICMP type information, IOS does not filter
non-initial fragments. If the deny ACE does not have ICMP type
information, IOS filter non-initial fragments.
Tests:
access-list 110 deny icmp h 100.5.214.1 any echo
access-list 110 perm ip a a
Rack2R5#sh int e 0/0 | i packets input
1184 packets input, 296528 bytes, 0 no buffer
Rack2R5#sh int e 0/0 | i packets input
1186 packets input, 297644 bytes, 0 no buffer
Rack2R5#sh int e 0/0 | i packets input
1189 packets input, 298050 bytes, 0 no buffer
Rack2R5#sh int e 0/0 | i packets input
access-list 110 deny icmp h 100.5.214.1 any
access-list 110 perm ip a a
Rack2R5#sh int e 0/0 | i packets input
1363 packets input, 378598 bytes, 0 no buffer
Rack2R5#sh int e 0/0 | i packets input
1363 packets input, 378598 bytes, 0 no buffer
Rack2R5#sh int e 0/0 | i packets input
1363 packets input, 378598 bytes, 0 no buffer
This is in agreement with following Cisco URL:
"When this happens, only the fragment containing the beginning of the
packet contains the Layer 4 information, such as TCP or UDP port
numbers, ICMP type and code, and so on."
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225seb/scg/s
wacl.htm#wp1102021
It states that ICMP type is layer 4 information and present on the
initial fragment. IOS considers this and does not filter ICMP fragments
if the deny ACE contains ICMP type.
Deal's book, page 282 says:
"..you can use the fragments keyword with ICMP and ICMP message types
because ICMP is a layer 3 protocol"
As I see it, ICMP type is not a layer 4 information as it is TCP and UDP
port. But IOS behavior as if it was.
The same happens with Flow-Tools, where ICMP types are on the same
fields of TCP ports.
What is your opinion about this?
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:30 GMT-3