Oops, DNS (record lookups) also at the Control Plane - according to the
book. Maybe we finally have the definitive answer as far as Cisco is
concerned....

-----Original Message-----
From: Darren [mailto:[email protected]] 
Sent: 08 December 2010 15:06
To: '[email protected]'
Subject: RE: CCIE_Security Digest, Vol 53, Issue 58

Sorry to bring this one back up, but just reading Cisco Press Router
Security Strategies and DNS (Zone Transfer) falls under 'Control Plane'.
Note; this is zone transfer only (TCP) not DNS name resolution for a
client.....

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: 17 November 2010 16:13
To: [email protected]
Subject: CCIE_Security Digest, Vol 53, Issue 58

Send CCIE_Security mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://onlinestudylist.com/mailman/listinfo/ccie_security
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CCIE_Security digest..."


Today's Topics:

   1. Re: class maps for arp and cdp packets (Tyson Scott)
   2. Re: OEQ Question clarification: GET VPN ('Segun Daini)
   3. Re: DNS part of which plane (Kingsley Charles)


----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Nov 2010 16:25:30 -0500
From: "Tyson Scott" <[email protected]>
To: "'Eugene Pefti'" <[email protected]>, "'Kingsley Charles'"
        <[email protected]>,   <[email protected]>
Subject: Re: [OSL | CCIE_Security] class maps for arp and cdp packets
Message-ID: <005401cb85d4$cc68eae0$653ac0...@com>
Content-Type: text/plain; charset="us-ascii"

Why would a router really care about BPDU's?  And with CDP you can run "no
cdp enable" or "no cdp run" on both the router and the switch so I am not
sure why it really needs to be a function on the CPPr features.  I don't
think Cisco needs to develop stuff just for the heck of it ;).

 

Regards,

 

Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.

Mailto:  <mailto:[email protected]> [email protected]

Telephone: +1.810.326.1444, ext. 208

Live Assistance, Please visit:  <http://www.ipexpert.com/chat>
www.ipexpert.com/chat

eFax: +1.810.454.0130

 

IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
<http://www.ipexpert.com/communities> www.ipexpert.com/communities and our
public website at  <http://www.ipexpert.com/> www.ipexpert.com

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Eugene Pefti
Sent: Tuesday, November 16, 2010 12:34 AM
To: 'Kingsley Charles'; [email protected]
Subject: Re: [OSL | CCIE_Security] class maps for arp and cdp packets

 

And it just occurred to me. Let's say I want to filter all BPDU traffic from
switches connected to the router. Just theoretically.

"match protocol bpdu" doesn't exist. Does it mean that I can't filter BPDU
with CPPr whatsoever ?

 

Eugene

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Kingsley
Charles
Sent: Monday, November 15, 2010 7:12 AM
To: [email protected]
Subject: [OSL | CCIE_Security] class maps for arp and cdp packets

 

Hi all

I want to drop ARP and CDP packets coming to router using control plane
cef-exception interface. 

As you may be aware that CPPr doesn't support class maps with protocol
recognization i.e., using "match protocol"

I am not able to find options to define an ACL for CDP and ARP. 

Any thoughts?



With regards
Kings

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
</archives/ccie_security/attachments/20101116/629d3b8a/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 16 Nov 2010 20:18:52 -0800 (PST)
From: 'Segun Daini <[email protected]>
To: "[email protected]" <[email protected]>,
        "[email protected]" <[email protected]>
Cc: "[email protected]"
        <[email protected]>
Subject: Re: [OSL | CCIE_Security] OEQ Question clarification: GET VPN
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

<p>To add, when the encryption is between the end nodes, we have transport
mode. But when the encryption is between gateways we have tunnel mode. </p>
<p>Normally, because for transport, the encryption is done on the
originating host, the ip is preserved. While for tunnel mode its not.  But
GET is an exception. </p>
<p>Regards. <br><br><br></p>
<p>Sent from Yahoo! Mail on Android</p>



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
</archives/ccie_security/attachments/20101116/0008d2d5/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 17 Nov 2010 11:42:48 +0530
From: Kingsley Charles <[email protected]>
To: Tyson Scott <[email protected]>
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] DNS part of which plane
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="windows-1252"

Thanks for your detailed explanation.

With regards
Kings



On Wed, Nov 17, 2010 at 2:44 AM, Tyson Scott <[email protected]> wrote:

> It is not there, who would ever use DNS on a router in production.  In
real
> world we would never look at DNS as control or management function on a
> router.  It is a protocol that would typically only be seen in the data
> plane.
>
>
>
> It is not control-plane.  You need to separate what is the control-plane
> and what CPP CPPr are.  They are not the same thing.
>
>
>
> Here is a definition of the control-plane
>
> In routing, the control plane is the part of the router architecture that
> is concerned with drawing the network map, or the information in a
(possibly
> augmented) routing table that defines what to do with incoming packets.
> Control plane functions, such as participating in routing protocols, run
in
> the architectural control element.[1] In most cases, the routing table
> contains a list of destination addresses and the outgoing interface(s)
> associated with them. Control plane logic also can define certain packets
to
> be discarded, as well as preferential treatment of certain packets for
which
> a high quality of service is defined by such mechanisms as differentiated
> services.
>
>
>
> What fits under that definition? ARP, IGP, BGP, IGMP, PIM, and other
> protocols that "glue" the network together just as Yusuf describes in his
> book.  These protocols can also be very easily identified because these
> protocols will typically terminate on the interface of the router.  But
then
> BGP, IGMP, and PIM have exceptions to that typical rule as well.  I also
> think that if the router can run without it then you can't define it as
> fitting into any portion of the router as a primary function.
>
>
>
> Is that a full list of everything that may terminate on the control-plane,
> no.  But everything else starts to become "may be a control-plane
function,
> may be a data plane function".  VPN traffic for example may terminate on
the
> control plane or it may simply flow thru the router on the forward path.
If
> you terminate it on the control-plane then you need to take VPN traffic
into
> consideration in your protection mechanisms using protection mechanisms
like
> "call admission control".  But that isn't there by default because 90% of
> the routers in production don't provide encryption services so 90% of the
> time VPN is not a control-plane function.  So if we go based on a 51% rule
> is the norm that means that VPN is a data plane function right? No we
can't
> really say that either.  But trying to fit protocols into a nice box of it
> is data plane/control plane/management plane just doesn't work.  There are
> too many exceptions to make any good rule of thumb.
>
>
>
> Simply said it is not a control-plane function, it is not a management
> plane function it is  not a data plane function.  It is a process that
runs
> on the router.  Controlling access to it would be controlled on the host
> control plane sub-interface.  Where is the management-interface also
> defined?  Control-plane host.  Does that make these other protocols
> control-plane protocols?  No they are protocols that may run on the host
> control-plane in management functions.
>
>
>
> Regards,
>
>
>
> Tyson Scott - CCIE #13513 R&S, Security, and SP
>
> Managing Partner / Sr. Instructor - IPexpert, Inc.
>
> Mailto: [email protected]
>
> Telephone: +1.810.326.1444, ext. 208
>
> Live Assistance, Please visit: www.ipexpert.com/chat
>
> eFax: +1.810.454.0130
>
>
>
> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
> CCIE (R&S, Voice, Security & Service Provider) certification(s) with
> training locations throughout the United States, Europe, South Asia and
> Australia. Be sure to visit our online communities at
> www.ipexpert.com/communities and our public website at www.ipexpert.com
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Eugene Pefti
> *Sent:* Monday, November 15, 2010 10:41 PM
> *To:* 'Kingsley Charles'; 'Pieter-Jan Nefkens'
>
> *Cc:* [email protected]
> *Subject:* Re: [OSL | CCIE_Security] DNS part of which plane
>
>
>
> If we don?t know ?why? for this ?chicken-egg? debate who will be the
> authority to answer it, folks.
>
> I would never put DNS to management plane let it be Cisco world or
anything
> else. And Kings? finding supports it.
>
>
>
> Eugene
>
>
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Kingsley Charles
> *Sent:* Sunday, November 14, 2010 9:32 PM
> *To:* Pieter-Jan Nefkens
> *Cc:* [email protected]
> *Subject:* Re: [OSL | CCIE_Security] DNS part of which plane
>
>
>
> If DNS is part of management plane then why isn't it in the following
list:
>
> router2(config-cp-host)#management-interface g0/0 allow ?
>   beep    Beep Protocol
>   ftp     File Transfer Protocol
>   http    HTTP Protocol
>   https   HTTPS Protocol
>   snmp    Simple Network Management Protocol
>   ssh     Secure Shell Protocol
>   telnet  Telnet Protocol
>   tftp    Trivial File Transfer Protocol
>   tl1     Transaction Language Session Protocol
>   tls     Transport Layer Security Protocol
>
>
> With regards
> Kings
>
> On Tue, Nov 9, 2010 at 12:50 PM, Pieter-Jan Nefkens <?> wrote:
>
> Hi Kings,
>
>
>
> But DNS is used for management. You can use it, for example, for URL
> filtering, certificate enrollment / verification, etc...
>
> And you might want to consider to let DNS traffic leave out of the
> management interface (thus out-of-band certificate enrollment,  RBL
checks,
> url filtering, etc). And that would mean that dns would be part of the
> management plane.
>
>
>
> For me, the control plane basically is the CPU in the router that talks
> with the data plane and allows the setting of hardware entries in the data
> plane and handle all traffic that can't be handled in the data-plane.
>
> This includes the arp entries (arp is then placed in the data plane),
> application layer inspection that can't be handled in hardware, changes of
> routing entries, etc..
>
>
>
> The management plane for me is mostly the ways to configure traffic and
how
> the router handles traffic and applications. And then in general all
traffic
> that is nog immediately part of routing / switching. (the handling of
> routing protocols is of course on the control plane, as it comes in from
all
> interfaces), but you might want to restrict management traffic
>
>
>
> HTH
>
>
>
> Pieter-Jan
>
>
>
> On 9 nov 2010, at 06:33, Kingsley Charles wrote:
>
>
>
> Tyson, DNS is not required to build the network hence I agree it's not
part
> of control plane.
>
> DNS is a protocol that builds the Name to IP address table. If CDP is part
> of the control plane which doesn't help much to operate the network then I
> feel DNS can also be part of control plane :-)
>
>
>
>
> With regards
> Kings
>
> On Tue, Nov 9, 2010 at 10:07 AM, Tyson Scott <[email protected]> wrote:
>
> Is DNS necessary, from a router perspective, for the network to operate?
>
>
>
> Control plane is only network services that "glue" the network together.
>
>
>
> Routing protocols,
>
>
>
> Regards,
>
>
>
> Tyson Scott - CCIE #13513 R&S, Security, and SP
>
> Managing Partner / Sr. Instructor - IPexpert, Inc.
>
> Mailto: [email protected]
>
> Telephone: +1.810.326.1444, ext. 208
>
> Live Assistance, Please visit: www.ipexpert.com/chat
>
> eFax: +1.810.454.0130
>
>
>
> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
> CCIE (R&S, Voice, Security & Service Provider) certification(s) with
> training locations throughout the United States, Europe, South Asia and
> Australia. Be sure to visit our online communities at
> www.ipexpert.com/communities and our public website at www.ipexpert.com
>
>
>
> *From:* Kingsley Charles [mailto:[email protected]]
> *Sent:* Monday, November 08, 2010 11:06 PM
> *To:* Tyson Scott
> *Cc:* Eugene Pefti; [email protected]
>
>
> *Subject:* Re: [OSL | CCIE_Security] DNS part of which plane
>
>
>
>
>
> Hi Tyson
>
> Can you please let me know the reason for having DNS in management plane.
> How does the DNS help to manage the deivce?
>
> I am not getting the picture.
>
> With regards
> Kings
>
> On Tue, Nov 9, 2010 at 8:08 AM, Tyson Scott <[email protected]> wrote:
>
> DNS is management plane.  It is not a service that glues the L3 network
> together.
>
>
>
> Regards,
>
>
>
> Tyson Scott - CCIE #13513 R&S, Security, and SP
>
> Managing Partner / Sr. Instructor - IPexpert, Inc.
>
> Mailto: [email protected]
>
> Telephone: +1.810.326.1444, ext. 208
>
> Live Assistance, Please visit: www.ipexpert.com/chat
>
> eFax: +1.810.454.0130
>
>
>
> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
> CCIE (R&S, Voice, Security & Service Provider) certification(s) with
> training locations throughout the United States, Europe, South Asia and
> Australia. Be sure to visit our online communities at
> www.ipexpert.com/communities and our public website at www.ipexpert.com
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Eugene Pefti
> *Sent:* Sunday, November 07, 2010 3:23 AM
> *To:* 'Kingsley Charles'
>
>
> *Cc:* [email protected]
> *Subject:* Re: [OSL | CCIE_Security] DNS part of which plane
>
>
>
> That?s right. We see all ports that open on the router that belongs to the
> so-called host subinterface of Control Plane. What are debating about then
?
> ;)
>
> I didn?t find that DNS belongs to management plane in Cisco?s official
> documentation. Perhaps Yusuf in his flash cards is not right as the list
of
> protocols mentioned in the Figure for this question is too big. Unless I
> confuse entirely the concept of Control and Management Plane
>
>
>
> *From:* Kingsley Charles [mailto:[email protected]]
> *Sent:* Sunday, November 07, 2010 12:56 AM
> *To:* Eugene Pefti
> *Cc:* [email protected]
> *Subject:* Re: [OSL | CCIE_Security] DNS part of which plane
>
>
>
> Eugene, the O/P is self explanatory. The show control-plane host openshows
all the port that the router is listening to. The
> O/P has port 22 and 23 which is ssh and telnet respectively. Does that
mean
> telnet and ssh are control plane protocols?
>
> The O/P includes management, control and service protocol port numbers.
> ISAKMP is in service plane right, you can 500 and 4500 in the O/P too.
>
>
> With regards
> Kings
>
> On Sun, Nov 7, 2010 at 1:13 PM, Eugene Pefti <[email protected]>
> wrote:
>
> It?s a good point, Kings.
>
> Our customer uses their routers as DNS servers at their remote offices and
> the traffic destined to the router itself can be falling under the
> management plane.
>
> I thought that you control access to the router via a regular ACL which I
> still do by applying it to different VLAN interfaces.
>
> But when I query the router to show me open ports under the control plane
I
> see DNS on the list as well. Hence DNS traffic is from control-plane ;)
>
>
>
> Router_LAB#show control-plane host open
>
> Active internet connections (servers and established)
>
> Prot               Local Address             Foreign
> Address                  Service    State
>
>  tcp                        *:22                         *:0
> SSH-Server   LISTEN
>
>  tcp                        *:23
> *:0                   Telnet   LISTEN
>
>  tcp                        *:53                         *:0
> DNS Server   LISTEN
>
>  udp                        *:53                         *:0
> DNS Server   LISTEN
>
>  udp                        *:67                         *:0
> DHCPD Receive   LISTEN
>
>  udp                      *:2887
> *:0                      DDP   LISTEN
>
>  udp                       *:123
> *:0                      NTP   LISTEN
>
>  udp                      *:4500
> *:0                   ISAKMP   LISTEN
>
>  udp                       *:500
> *:0                   ISAKMP   LISTEN
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Kingsley Charles
> *Sent:* Saturday, November 06, 2010 11:52 PM
> *To:* [email protected]
> *Subject:* [OSL | CCIE_Security] DNS part of which plane
>
>
>
> Hi all
>
> As per the Yusuf flash cards, DNS is part of the Management plane.
>
> Management plane is used to manage the device and control plane is used to
> dynamically build the network.
>
> The DNS builds the network by resolving the FQDN to IP address.
>
> I think, DNS should be in the control plane list.
>
> Any thoughts?
>
> With regards
> Kings
>
>
>
>
>
>
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
>
>
> ---
>
> Nefkens Advies
>
> Enk 26
>
> 4214 DD Vuren
>
> The Netherlands
>
>
>
> Tel: +31 183 634730
>
> Fax: +31 183 690113
>
> Cell: +31 654 323221
>
> Email: [email protected]
>
> Web: http://www.nefkensadvies.nl/
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/ccie_security/attachments/20101117/43b03b18/attachment.html>

End of CCIE_Security Digest, Vol 53, Issue 58
*********************************************

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to