[c-nsp] Naming Conventions

Mon Aug 23 13:08:30 EDT 2004

On Monday 23 August 2004 18:34, Paul Stewart wrote:
> This is a good question...
>
> I don't like the idea of telling the world what kind of equipment we
> have at our edge and/or servicing a customer.... we wanted to adopt a
> method that is easy for our techs to understand but for an "outsider"
> not easy to understand.

In smaller environments it would be nice to keep it simple, for instance, 
using cr (core), br (border) and cust-gw (access), along with router 
slots/ports for the PTR names.

In some cases, where it isn't such a big deal in revealing this information, 
the same names could represent the forward DNS (A record) as well, just for 
quick access by administrators.

>
> As for the port issue, we will probably use slot/port methods which
> still doesn't tell the outsider much stuff such as speed, port type
> (ATM, Ethernet etc.)

True.

>
> I guess our approach is to hide as much as possible but not make it
> difficult for us to understand our own network.  The geographic naming
> is fine too in my opinion (naming the POP's after where they are
> located) as it doesn't tell them where in a city the equipment is
> located or anything...

This sounds good too. This is especially useful, from a customer perspective, 
when tracking what path packets will take when exiting the network, 
especially in cases where your IGP (for one reason or another) has 
reconverged with a new path.

>
> Really, our initiative is geared because we use gw-7513, gw-3640 etc.
> and are running into duplicates plus we feel it's better to not provide
> that information to the world.  If a new BGP exploit comes out for
> example, then a hacker knows right away to target gw-7513 versus gw-1710
> for example...

Yes, I wouldn't recommend this naming convention, as you say, because of 
possible future duplicity, but more so because of the hardware type info you 
can give away.

Also, some picky customers won't be too happy knowing they are peering with 
7200 only to exit your border on a 3600 :).

>
> The final thing that we are changing is customer names on interfaces.
> We have a number of customers that we have used
> gw-cust-customername.domain.net as example.  This gives too much
> information away to people as to who are customers are and how they are
> connected...

I agree here. Customer's p-t-p IP's should be replaced by your generic/DEFAULT 
PTR name. Like in my case, 'ip-net-1.2.3.4.domain.com', as an example. In 
these cases, I don't even create a forward/A record for this, just the PTR. 

In cases where you would like to identify particular services off your network 
(to help track abusers and all), you could append -ppp-, -ppp-dial-, -adsl-, 
e.t.c., to the PTR record.

I would also recommend using this same convention on equipment/interfaces you 
wouldn't want displayed within a traceroute/PTR query e.g. say some switch, 
or some bandwidth manager, or some device you really want to hide, you could 
just give part of your DEFAULT PTR.

Mark.

>
> Take care,
>
> Paul
>
> On Mon, 2004-08-23 at 12:17, james at thehamptonfamily.us wrote:
> > I to am in the process of developing a standard naming convention, but
> > was afraid of giving away to much info when using model numbers and port
> > IDs in names. Am I being to paranoid, or can a hacker who is profiling a
> > company actually use this info in some way?
> >
> > James
> >
> > > On Sun, 22 Aug 2004, Paul Stewart wrote:
> > >> We're a mid-sized ISP and I'm looking at trying to standardize our
> > >> naming conventions for routers/switches/firewalls.
> > >>
> > >> Just looking to see what the "norm" is that makes sense.  Currently we
> > >> use gw-7513, gw-5513 etc. but this doesn't really make sense nor is it
> > >> good from a security perspective in my opinion.
> > >
> > > You'll probably get lots of different answers to this :-)
> > >
> > > I've found it's better to name devices based on what they do, not that
> > > they are.  That way if you replace that 5513 with a 6513, you don't
> > > need to change DNS, and potentially other things like monitoring
> > > software, etc...
> > >
> > > I've worked for a mid-size ISP and designed the network device naming
> > > conventions for them, so I have some experience here.  These are just
> > > my thoughts.  You may choose to do something completely different.
> > >
> > > What I've done in the past is something like this:
> > >
> > > core routers
> > > ------------
> > > crX.location/pop.state/country.isp.net
> > >
> > > I see lots of places use either a general location ID, such as "paix01"
> > > or or something based on telco CLLI codes, like "nycmny" for New York
> > > City (Manhattan).
> > >
> > > example:
> > > cr1.paix01.ca.isp.net
> > >
> > > This would normally point to the primary loopback interface on the
> > > device specific interfaces could be identified in much the same way
> > >
> > > p1-0-0.cr1.paix01.ca.isp.net
> > > t3-2-0-0.cr1.paix01.ca.isp.net
> > >
> > > customer attach/access routers
> > > ------------------------------
> > > arX.same-format-as-above
> > >
> > > Specific interfaces could be identified the same way.  Interfaces with
> > > sub-interfaces (frame relay, ATM, 802.1q ethernet trunks, etc) could
> > > also be identified the same way
> > >
> > > t1-1-2-1-24.ar1.paix01.ca.isp.net
> > > s2-0-17-0.ar1.paix01.ca.isp.net
> > > a2-0-1-305.ar2.paix01.ca.isp.net
> > >
> > > core switches
> > > -------------
> > > csX.same-format-as-above
> > >
> > > If your switches are doing any layer 3 routing, you can label specific
> > > interfaces
> > >
> > > g5-1.cs1.paix01.ca.isp.net
> > > f2-48.cs2.paix01.ca.isp.net
> > >
> > > distribution/access switches
> > > ----------------------------
> > > asX.same-format-as-above
> > >
> > > firewalls
> > > ---------
> > > fwX.same-format-as-above
> > >
> > > specific interfaces would depend on your firewall's interface naming
> > > standards, e.g. ethernet0,1,2.... for Cisco PIXes, etc.  I'd recommend
> > > that rather than using things like "dmz1" or "outside0" because that
> > > can reveal more than you want about your network architecture.
> > >
> > > jms
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/