From: David Clarkson (DaClarkson@symantec.com)
Date: Tue Sep 23 2003 - 12:01:42 GMT-3
Hey Scott,
Thanks for the info.
In fact the core does no tunnel termination. It routes a mixture of both
GRE tunnels and native IP traffic.
The ultimate goal is to do IDS for both the native-IP traffic (all
detection methods) and pattern matching for the non-encrypted IP packets
within GRE tunnels. I know it is messy... but it is a PoC more than
anything.
Ideally a GRE handler would be built into the IDS itself that could strip
the GRE header and inspect IP packets (if unencrypted) as per usual, or
for non-supported protocols -> /dev/null.
Regards,
Dave
"Scott Morris" <swm@emanon.com>
09/24/2003 12:33 AM
Please respond to swm
To: "'David Clarkson'" <DaClarkson@symantec.com>, "'Brian McGahan'"
<bmcgahan@internetworkexpert.com>
cc: <ccielab@groupstudy.com>
Subject: RE: GRE access lists
If you manage to change precedence before it's put into the tunnel (your
access layer), you could just as well have a CBWFQ policy on your
distribution layer as a match all class for IP Prec 0 AND GRE protocol.
Then route it to null, police it, or whatever you want to accomplish
with it.
If you are applying your markings on your access layer, you really can't
filter at that level. But the next immediate router you can.
If you WANT your non-IP traffic to go through and just not pass the IDS
sensor, do you have an alternate path through the core? Policy-based
routing may be able to give you an alternate method through. That way
your non-IP stuff (or GRE stuff entirely) isn't hitting the port/vlan
that the IDS sensor is monitoring.
Looking at your toplogy though, I'm missing something. Are your tunnels
terminating in the core and re-routing/re-tunneling to the other remote
ends? If they aren't, your IDS sensor isn't going to do much good to
the "inside" of the GRE packets.
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP, JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
David Clarkson
Sent: Tuesday, September 23, 2003 2:10 AM
To: Brian McGahan
Cc: ccielab@groupstudy.com
Subject: RE: GRE access lists
Your right, CIDS 4.0 has no handler for precendence values. I am trying
to
find a way to get the switch to provide a gig monitor that spans only IP
packets from the GRE tunnel. That way, the IDS does not waste time
processing non-IP traffic which is does not understand anyway. The
precendence option is very interesting, and no IP precendence has been
set
at this point.
"Brian McGahan" <bmcgahan@internetworkexpert.com>
09/23/2003 03:04 PM
To: "'David Clarkson'" <DaClarkson@symantec.com>
cc: <ccielab@groupstudy.com>
Subject: RE: GRE access lists
Dave,
Do you already have a QoS policy that uses IP
Precedence
values?
If not, you can classify all IP packets with a particular precedence
value before they are encapsulated in GRE. All other non-IP packets
will have a default ip precedence of 0. The GRE header will inherit the
precedence value of the packet encapsulated. The config would be
something like this:
class-map match-all IP
match protocol ip
!
policy-map SET_IP_PREC
class IP
set precedence 1
!
interface Tunnel0
service-policy output SET_IP_PREC
The problem is going to be whether the IDS supports
checking or
ignoring packets based on precedence values. I'm not sure if Cisco's
IDS sensors can do this... What kind of IDS are you using?
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 708-362-1418 (Outside the US and Canada)
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> David Clarkson
> Sent: Monday, September 22, 2003 11:42 PM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com
> Subject: RE: GRE access lists
>
> Core Dist Acc
>
> ------------/ GRE Tunnel (DECNET, IP, IPX)
> /-----------/-----------/ GRE Tunnel (DECNET, IP, IPX)
> IDS------| /-----------/ GRE Tunnel (DECNET, IP, IPX)
> /-----------/-----------/ GRE Tunnel (DECNET, IP, IPX)
> ------------/ GRE Tunnel (DECNET, IP, IPX)
>
> The tunneling is providing multi protocol access between
geographically
> disparate access layer networks. Tunneling is across the IP only dist
and
> core layers. The IDS sits in on the core because placing them at the
> access layer (before GRE) is cost prohibitive.
>
>
>
>
>
>
>
>
>
> "Brian McGahan" <bmcgahan@internetworkexpert.com>
> 09/23/2003 02:01 PM
>
>
> To: "'David Clarkson'" <DaClarkson@symantec.com>
> cc: <ccielab@groupstudy.com>
> Subject: RE: GRE access lists
>
> Dave,
>
> What does your topology look like (ascii plz), where does
the
> tunneling occur, and where does the IDS occur?
>
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 708-362-1418 (Outside the US and Canada)
>
> -----Original Message-----
> From: David Clarkson [mailto:DaClarkson@symantec.com]
> Sent: Monday, September 22, 2003 10:44 PM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com; 'Jonathan V Hays'
> Subject: RE: GRE access lists
>
>
> I am trying to apply security (CIDS) on the IP packets in the GRE, but
> want to avoid the non-IP packets in the GRE as they seem to cause
> problems.
>
> Thx
> Dave
>
>
>
>
> "Brian McGahan" <bmcgahan@internetworkexpert.com>
> 09/23/2003 01:32 PM
>
> To: "'Jonathan V Hays'" <jhays@jtan.com>, "'David
> Clarkson'" <DaClarkson@symantec.com>
> cc: <ccielab@groupstudy.com>
> Subject: RE: GRE access lists
>
>
> David,
>
> What exactly are you trying to accomplish?
>
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 708-362-1418 (Outside the US and Canada)
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Jonathan V Hays
> > Sent: Monday, September 22, 2003 10:02 PM
> > To: 'David Clarkson'
> > Cc: ccielab@groupstudy.com
> > Subject: RE: GRE access lists
> >
> > Dave,
> >
> > RFC 2784 (GRE) does indicate that there is a Protocol Type field in
> the
> > GRE packet header, which contains the payload's protocol type (using
> the
> > RFC 1700 ETYPE number). So filtering or classifying based on the
> > encapsulated protocol is theoretically possible.
> >
> > But other than providing the above information, I can't help much
> more.
> > I don't see how a Cisco access-list can be used to access this
field.
> >
> > See the following URL for a list of extended access-list fields:
> >
> >
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
> > fipras_r/1rfip1.htm#1017448
> >
> > Perhaps there is some other way the IOS can access the GRE Protocol
> Type
> > field?
> >
> > Anyone?
> >
> > Jonathan
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > David Clarkson
> > Sent: Monday, September 22, 2003 10:38 PM
> > To: Jonathan V Hays
> > Cc: ccielab@groupstudy.com
> > Subject: RE: GRE access lists
> >
> >
> > I am trying to classify the encapsulated protocol so I can treat
> > different encapsulated protocols differently within the same GRE
> > tunnel.
> >
> > Regards,
> > Dave
> >
> > ***Get your CCIE and a FREE vacation: Shop.GroupStudy.com***
> >
>
This archive was generated by hypermail 2.1.4 : Wed Oct 01 2003 - 07:24:34 GMT-3