From: Biggs, Jeff \(M/CIO/BIE\) (JBiggs@usaid.gov)
Date: Mon Jun 18 2007 - 08:38:36 ART
Thanks Alexei. Sunday morning I got up and took a fresh look at this and realized the issues after reviewing the Showit again (Permit instead of deny), etc....
As far as the assumption that the "infected" device is behind R6, would that be a question for the proctor (say if I were in the LAB)?
If I Explained that I understand the requirement for dropping packets lengths 110, but should I assume the rouge device is not R6 itself, but behind it? Would that be a valid question or would it be considered "fishing" for an answer?
Jeffrey Biggs
Sr. Network Engineer
M/CIO/BIE
CCNP, CCDA
240-646-5003
jbiggs@usaid.gov
This e-mail is intended for the addressee only. If you are not the intended recipient, please be aware that the unauthorised use or disclosure of the information it contains, or the unauthorised copying or re-transmission of the e-mail are strictly prohibited. Such action may result in legal proceedings. If the e-mail has been sent to you in error, please accept our apologies, advise the sender as soon as possible and then delete the message. Under the Freedom of Information Act 2000 / Data Protection Act 1998, the contents of this e-mail, whether it is marked confidential or otherwise, may be disclosed.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of asadovnikov
Sent: Sunday, June 17, 2007 4:08 PM
To: ccielab@groupstudy.com
Subject: RE: NMC DOIT 5.14.3 QOS: Would this solution work?
JB,
Here are some issues which I can see with your solution:
1) The logic of the policy map is to drop traffic which is matched by the
class and the class will match what is matched by the ACL.
As such you want the ACL to permit what you want to get dropped. For
example you want the ACL to permit traffic coming from
FEC0::16:6 and you ACL is denying it (versus to permitting) which will
result in result oposite to the intended.
2) The task says that the protocol and port are not known ('random'), which
is not the same as "undetermined-transport". The fact
that you do not know what transport will be does not mean that router
would not be able to detemine it. For example if the packet
happens to be ipv6 telnet packets, the router would not take it as
undetermined transport and hence ACE would not match it.
So if I were to re-write your solution to take care of two issues discussed
above (but not of the issue #3 discussed below) here is what I get:
class-map match-all FLOOD
match access-group name FLOODv6
match packet length min 110 max 110
!
policy-map FLOOD
class FLOOD
drop
!
ipv6 access-list FLOODv6
permit ipv6 host FEC0::146:6 host FEC0::146:1
permit ipv6 host FEC0::146:6 host FEC0::16:1
permit ipv6 host FEC0::146:6 host FEC0::12:1
permit ipv6 host FEC0::16:6 host FEC0::146:1
permit ipv6 host FEC0::16:6 host FEC0::16:1
permit ipv6 host FEC0::16:6 host FEC0::12:1
!
int fa0/0.16
Service-policy input FLOOD
int fa0/0.146
Service-policy input FLOOD
3) The task is looking for a solution for traffic which is not originated
and probably not terminated on routers of your POD.
If you think about real application, the flood attack would be coming
from outside of your network and will target hosts
within your network, then you can use filtering on you border router to
block the traffic. Imagine that there is a workstation
behind R6 which is infected with a virus and sending the traffic you are
trying to block.
This is what makes matching on mac address important, without such match
you can not distibguish packets coming via R4
(known good traffic) from packets coming from elsewhere (suspected bad
traffic), becouse you do not know what the actual
source or destination IPv6 addresses are.
Going back to the application example above, chances are that there is
not a virus on R6, so the only significance of
IPv6 addresses on R6 is that it allows you to test your solution, but
solution needs to accomadate for other IPv6 source
addresses.
Similary you should not make an assumption that packets are addressed to
R1, although in testing the solution you will
use IPv6 ping from R4 and R6 to R1.
HTH,
Alexei
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jeffrey Biggs
Sent: Saturday, June 16, 2007 9:58 PM
To: ccielab@groupstudy.com
Cc: 'Biggs Jeff'
Subject: NMC DOIT 5.14.3 QOS: Would this solution work?
I am trying to prevent an IPV6 flood attack of random protocol,
source/destination and ports, but length is always 110. All packets are
attacking on the R1 from R6 (both interfaces below attach to R1). But no
problems from R4 (on the ::146:0 subnet). So block 110 length packets from
R6, but leave R4 alone. The solution on Netmasters shows them not matching
the MAC address of R4, but matching IPv6 traffic and Length. This is the
solution I came up with, I wanted to know if it would work.
Will it block R4 also?
class-map match-all FLOOD
match access-group name FLOODv6
match packet length min 110 max 110
!
policy-map FLOOD
class FLOOD
drop
!
ipv6 access-list FLOODv6
deny ipv6 host FEC0::146:6 host FEC0::146:1 undetermined-transport
deny ipv6 host FEC0::146:6 host FEC0::16:1 undetermined-transport
deny ipv6 host FEC0::146:6 host FEC0::12:1 undetermined-transport
deny ipv6 host FEC0::16:6 host FEC0::146:1 undetermined-transport
deny ipv6 host FEC0::16:6 host FEC0::16:1 undetermined-transport
deny ipv6 host FEC0::16:6 host FEC0::12:1 undetermined-transport
permit ipv6 any any
!
int fa0/0.16
Service-policy input FLOOD
int fa0/0.146
Service-policy input FLOOD
Thanks,
JB
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:49 ART