security of IP address

security of IP address

Post by Barry Margoli » Tue, 03 May 2005 03:11:38





> hi there
>  if we use DHCP for assigning addresses for network interfaces, does
> the router verify all the messages and see if the packets have proper
> IP - MAC combination, is it an optional feature in todays routers. Does
> the relevant RFC state anything about it.

I've heard of switches that have security options for this type of
check, but not routers.  The problem that a router has to deal with is
that the source of the traffic may be several hops away, in which case
the MAC will belong to the downstream router, not the source.

--

Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 
 
 

security of IP address

Post by prg » Tue, 03 May 2005 04:54:39



> hi there
>  if we use DHCP for assigning addresses for network interfaces, does
> the router ...

Initial DHCP requests are broadcast frames, so they are not forwarded
by a router.  This is why a DHCP server or relay agent must reside on
each IP subnet to service requests.

Quote:> ... verify all the messages and see if the packets have proper
> IP - MAC combination, ...

Well, the requesting machine doesn't have anything to distinguish it
except the MAC address -- it doesn't have an IP yet.

Quote:> ... is it an optional feature in todays routers. Does
> the relevant RFC state anything about it.
> If not the router, is there any other entity who performs this check

The dhcpd server can be set up to offer IPs based on "valid" MACs, ie.,
only give out IPs to MACs you've indicated in the configuration.
Configuration details depend on your server.

Without pre-configuring clients with an assigned client-indentifier the
MAC is really all you have to work with initially.  Thus, clients would
have to "register" their MAC address in order to acquire a lease.  This
can be done "in person" or by using an "enrollment" scheme for "first
time" network users similar to the way many college campuses do it
(since students bring in their own hardware with unknowable MACs and
in-person registering is out of the question).  Your own hardware MACs
are available to you once you collect them.

The approach you take will depend on your environment/setup and just
what your concerns are.  Desktops offer easier/different options as
opposed to laptops, especially laptops of guests/visitors.

hth,
prg
email above disabled

 
 
 

security of IP address

Post by Barry Margoli » Tue, 03 May 2005 05:21:13




> Without pre-configuring clients with an assigned client-indentifier the
> MAC is really all you have to work with initially.  Thus, clients would
> have to "register" their MAC address in order to acquire a lease.  This
> can be done "in person" or by using an "enrollment" scheme for "first
> time" network users similar to the way many college campuses do it
> (since students bring in their own hardware with unknowable MACs and
> in-person registering is out of the question).  Your own hardware MACs
> are available to you once you collect them.

I think you misunderstood the question.  He's not asking about security
during the DHCP process.  He wanted to know about what happens after an
IP has been assigned to a host -- can the router continuously verify
that the MAC that's using an IP is the one to which the IP was assigned?

BTW, to the OP -- did you know that most NICs provide the ability to
change the MAC?  So verifying MACs doesn't really provide all that much
security.

--

Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 
 
 

security of IP address

Post by Vernon Schryv » Tue, 03 May 2005 05:23:44




>Without pre-configuring clients with an assigned client-indentifier the
>MAC is really all you have to work with initially.  Thus, clients would
>have to "register" their MAC address in order to acquire a lease.  This
>can be done "in person" or by using an "enrollment" scheme for "first
>time" network users similar to the way many college campuses do it
>(since students bring in their own hardware with unknowable MACs and
>in-person registering is out of the question).  Your own hardware MACs
>are available to you once you collect them.

See also the DHCP authentication options.

I've never been able to understand how those could be useful.  It has
always seemed to me that the key distribution problem is a fatal
problem.  If you can distribute keys to only authorized hosts, then
you can probably also collect their MAC addresses (or not) and push
all security worries to upper levels (e.g. to IPSEC) where they must
be handled no matter how (in)secure DHCP might be.


 
 
 

security of IP address

Post by prg » Tue, 03 May 2005 07:40:39





> > Without pre-configuring clients with an assigned client-indentifier
the
> > MAC is really all you have to work with initially.  Thus, clients
would
> > have to "register" their MAC address in order to acquire a lease.
This
> > can be done "in person" or by using an "enrollment" scheme for
"first
> > time" network users similar to the way many college campuses do it
> > (since students bring in their own hardware with unknowable MACs
and
> > in-person registering is out of the question).  Your own hardware
MACs
> > are available to you once you collect them.

> I think you misunderstood the question.  He's not asking about
security
> during the DHCP process.  He wanted to know about what happens after
an
> IP has been assigned to a host -- can the router continuously verify
> that the MAC that's using an IP is the one to which the IP was
assigned?

> BTW, to the OP -- did you know that most NICs provide the ability to
> change the MAC?  So verifying MACs doesn't really provide all that
much
> security.

On second reading, I suspect you're "correct" in that the OP seems to
be concerned with "continuous" dhcp message authentication.  Other
traffic is handled with encryption, etc.

Bootup-logon authentication via ldap is used.

Unfortunately, I'm not aware of any implementation of RFC 3118
(Authentication for DHCP Messages) that is in wide use on a lan.

In any case, these are "end point" security measures and not "router
implemented, check every packet at the app protocol level", issues,
afaict.  Does not mean they don't exist -- especially as the folks
pushing this are Cisco.

Worse yet, RFC 3118 issues have gotten tangled up in IPv6
implementation issues, etc.  I.e, it's pretty much a mess, IMHO.

The only thing I'm aware of that _is_ implemented involves _remote_
clients and dhcp gateways.  Eg.,

http://www.strongsec.com/freeswan/dhcprelay/ipsec-dhcp-howto.html#toc1

Even in this case, "mobile IP" seems to be the way most are going.
Manual configuration, of a sorts, and proxy arp.

Not even the latest-n-greatest from MS is tackling these issues yet
beyond monitoring.  Eg.,
http://www.windowsecurity.com/articles/DHCP-Security-Part1.html
http://www.windowsecurity.com/articles/DHCP-Security-Part2.html

So, as near as I can see for the moment, you exercise "best practices",
accept that your practices may be less that optimal, and monitor just
which IPs/MACs are running on the network.  Linux "arpwatch" is handy
for this when teamed with some scripts for quicker alerts than watching
the dhcpd.leases file.

But, I do think you are right about what the OP was asking/hoping for.

regards,
prg
email above disabled

 
 
 

security of IP address

Post by Michael Heimin » Tue, 03 May 2005 07:48:00





>>Without pre-configuring clients with an assigned client-indentifier the
>>MAC is really all you have to work with initially.  Thus, clients would
>>have to "register" their MAC address in order to acquire a lease.  This
>>can be done "in person" or by using an "enrollment" scheme for "first
>>time" network users similar to the way many college campuses do it
>>(since students bring in their own hardware with unknowable MACs and
>>in-person registering is out of the question).  Your own hardware MACs
>>are available to you once you collect them.
> See also the DHCP authentication options.
> I've never been able to understand how those could be useful.  It has

Presume you have thin clients and want/need to identify them
while booting, ensure they always get the same IP and alike.
Using their MAC address comes in pretty handy. One or another
vendor might be able to tell you the addresses before you'll get
the systems, if you want to setup lots of them, this would allow
you to generate dhcpd.conf from a short script in a few
seconds.;)

[..]

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)

#bofh excuse 364: Sand fleas eating the Internet cables

 
 
 

security of IP address

Post by Vernon Schryv » Tue, 03 May 2005 09:20:27




Quote:>> See also the DHCP authentication options.

>> I've never been able to understand how those could be useful.  It has

>Presume you have thin clients and want/need to identify them
>while booting, ensure they always get the same IP and alike.
>Using their MAC address comes in pretty handy. One or another
>vendor might be able to tell you the addresses before you'll get
>the systems, if you want to setup lots of them, this would allow
>you to generate dhcpd.conf from a short script in a few
>seconds.;)

Yes, but that's irrelevant to the DHCP authentication options.
I worked with "thin clients" on the vendor side many years before the
marketoons invented phrase.  All of what I wrote and that you deleted
applies to them:

]                                                                It has
] always seemed to me that the key distribution problem is a fatal
] problem.  If you can distribute keys to only authorized hosts, then
] you can probably also collect their MAC addresses (or not) and push
] all security worries to upper levels (e.g. to IPSEC) where they must
] be handled no matter how (in)secure DHCP might be.

Putting MAC addresses in dhcpd.conf does no more for distributing
the RFC 3118 keys to those thin clients than putting MAC addresses
in BOOTP configuration files did 20 years ago.

How does a thin client get the secret key that it needs to authenticate
its requests to the DHCP server?  Without any keys, how can it
authenticate what a putative server says?  If it is particularly
svelte, it may be so thin that it has no writable, non-volatile
storage in which to save the key--and never mind whether that storage
has the least security that some of us think ought be associated
with key storages.

On the other hand, while walking around to the not so thin clients to
teach them their RFC 3118 secrets, you can usually also teach them
their IP addresses and everything else that DHCP chatter might convey.

RFC 3118 could address the threats listed in section 1.1 just as well
as "authentication" has stopped email spam or "authentication" made
Microsoft's ActiveX other than a gaping security hole.  "Authentication"
is not so magic that any incantation containing it solves security all
or any problems.


 
 
 

security of IP address

Post by James Carlso » Tue, 03 May 2005 20:28:50



> On the other hand, while walking around to the not so thin clients to
> teach them their RFC 3118 secrets, you can usually also teach them
> their IP addresses and everything else that DHCP chatter might convey.

One of the points of authentication is identification.  If I make the
grossly simplifying assumption that all of my legitimate DHCP clients
are PC-type devices (computers with humans attached), then an
authentication exchange in DHCP can simplify my network
administration.

Instead of keeping a database of MAC addresses around (which may well
change as users upgrade or repair hardware), I can keep user/password
data in the usual sorts of repositories.  When I see a given MAC
address presenting a given bit of authentication information, I can
then make a decision about whether to (a) grant an IP address [and
perhaps choose an appropriate local network for that address, if I
have multiple] and (b) add a filter to allow traffic from that node
through my forwarding process.

I agree that the simplification above is gross.  Non-PC-type devices
need something better, and key distribution becomes a decent problem
for them.  But for PCs and ordinary lusers, passwords are "good
enough" and prevent some obvious operational problems with having to
keep a database of MAC addresses in sync with the user population.

(For what it's worth, this is essentially the same problem that the
IEFT PANA working group is solving by other means.)

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

 
 
 

security of IP address

Post by Vernon Schryv » Wed, 04 May 2005 00:31:53




Quote:>One of the points of authentication is identification.  If I make the
>grossly simplifying assumption that all of my legitimate DHCP clients
>are PC-type devices (computers with humans attached), then an
>authentication exchange in DHCP can simplify my network
>administration.

>Instead of keeping a database of MAC addresses around (which may well
>change as users upgrade or repair hardware), I can keep user/password
>data in the usual sorts of repositories.  When I see a given MAC
>address presenting a given bit of authentication information, I can
>then make a decision about whether to (a) grant an IP address [and
>perhaps choose an appropriate local network for that address, if I
>have multiple] and (b) add a filter to allow traffic from that node
>through my forwarding process.

I'm not convinced.  One thing about MAC addresses is that they are
approximately globally unique, bu PCs with user passwords are not.
You're unlikely to make users type passwords every time their systems
need to renew a DHCP lease.  You'll probably instead let the password
be saved on the disk and used as needed.  That raises lots of issues,
from someone who uses several desktop systems, all of which can
authenticate themselves simultaneously as the same user, to
misplaced laptops in evil hands.

DHCP authentication is good for preventing some largely innocent
mistakes such as connecting to the wrong network.  It's more about
network hygiene than security.


 
 
 

security of IP address

Post by Greenhor » Wed, 04 May 2005 17:15:17


Hi
   I am aware of the fact that you can manually edit the MAC used by
the interface (atleast in Windows and Linux)
Also, by saying routers i didn't mean intermediate routers but the DHCP
relay agent that's nearest to the client (through which the packets
usually go), sorry for being unclear.

thanks

 
 
 

security of IP address

Post by James Carlso » Wed, 04 May 2005 20:53:28



> I'm not convinced.  One thing about MAC addresses is that they are
> approximately globally unique, bu PCs with user passwords are not.
> You're unlikely to make users type passwords every time their systems
> need to renew a DHCP lease.

Perhaps.

Quote:>  You'll probably instead let the password
> be saved on the disk and used as needed.

Or in RAM.  I'm no UI designer, but I'd expect that losing password
state when the system is shut down (or is put to sleep) probably isn't
that big a deal.  Even if it's lost after acquiring the DHCP lease, it
doesn't seem like that much of a problem to me: you just adjust the
lease to suit the tolerance of the user.

(And given the market success of the really wretched crash-every-few-
minutes and malware-hosting software that's out there, I'd say that
users apparently have great levels of tolerance for pain.  ;-})

Quote:>  That raises lots of issues,
> from someone who uses several desktop systems, all of which can
> authenticate themselves simultaneously as the same user, to
> misplaced laptops in evil hands.

Sure.  I don't think you'd want to substitute it for strong
authentication at the application layer.

Quote:> DHCP authentication is good for preventing some largely innocent
> mistakes such as connecting to the wrong network.  It's more about
> network hygiene than security.

I think the target market is essentially the same as that for PANA: a
minimal level of authentication necessary to connect to a hotel
network and the like.  Not guarding the gate at Fort Knox.

(Though we're probably saying essentially the same thing ...)

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

 
 
 

security of IP address

Post by glen herrmannsfeld » Thu, 05 May 2005 06:11:00


(snip)

Quote:> I think you misunderstood the question.  He's not asking about security
> during the DHCP process.  He wanted to know about what happens after an
> IP has been assigned to a host -- can the router continuously verify
> that the MAC that's using an IP is the one to which the IP was assigned?

Not if there is another router in between.

Quote:> BTW, to the OP -- did you know that most NICs provide the ability to
> change the MAC?  So verifying MACs doesn't really provide all that much
> security.

As far as I know, all do, though the software to do it
isn't always supplied.

In the olden days, it wasn't easy to put PROM on the same
chip as the ethernet control, so it depends on the driver
reading the PROM (or EPROM or EEPROM) and writing to the
appropriate register.

Also, some protocols (DECNet for one) require setting the MAC
based on the host address.

It might be that some now have the EEPROM on the same chip,
but the ability to use protocols like DECNet will still require
the ability to set the MAC address.

-- glen

 
 
 

security of IP address

Post by Vernon Schryv » Thu, 05 May 2005 00:04:29




Quote:>> I'm not convinced.  One thing about MAC addresses is that they are
>> approximately globally unique, bu PCs with user passwords are not.
>> You're unlikely to make users type passwords every time their systems
>> need to renew a DHCP lease.

>Perhaps.

I remember a lot of agony at my employer of the time, a UNIX vendor,
about how to deal with the equivalent authentication & authorization
problem for diskless NFS clients.  We never did find what seemed like
a slightly secure solution that even the spooky users in rooms with
steel walls would tolerate without complaining about having to type
too many passwords.  (Years before marketoons in the Windows world
started yammering about "thin clients," keeping servers with spinning
disks in vaults was evidently more convenient than moving disks between
UNIX workstations to vaults every morning and night.)

Quote:>> DHCP authentication is good for preventing some largely innocent
>> mistakes such as connecting to the wrong network.  It's more about
>> network hygiene than security.

>I think the target market is essentially the same as that for PANA: a
>minimal level of authentication necessary to connect to a hotel
>network and the like.  Not guarding the gate at Fort Knox.

>(Though we're probably saying essentially the same thing ...)

I think so.


 
 
 

security of IP address

Post by drwxr-xr- » Thu, 05 May 2005 08:47:29


["Followup-To:" header set to comp.os.linux.networking.]

Quote:> Hi
>    I am aware of the fact that you can manually edit the MAC used by
> the interface (atleast in Windows and Linux)
> Also, by saying routers i didn't mean intermediate routers but the DHCP
> relay agent that's nearest to the client (through which the packets
> usually go),
> sorry for being unclear.

Damned unclear.  

What the hell are you replying to???

Oh.  I see..  

Another Google poster that doesn't think quoted text is necessary.

 
 
 

1. Network Security: I.P. Address With Corresponding Mac Address

Hi.

I have a home LAN that will soon have ADSL access.  I am trying to
give only some of the users on my LAN Internet access while
prohibiting others from doing so.  One method I thought of is matching
IP addresses to corresponding mac addresses.  That is, my Linux server
will check to make sure that a certain computer that has been assigned
a certain IP address will have a certain mac address before access is
given.  I haven't been able to locate such an option in the I.P.
Masquerading software or the IPChains software.  I do not want to
modify the C++ source code to do so unless it is absolutely necessary.

Any other suggestions is welcomed.

B.T.

2. VT100 Graphics -> Postscript

3. Changing IP address on Solaris 9 with multiple virtual IP addresses

4. Logitech Cordless Desktop: Need help!

5. WANTED: pingmac <IP ADDR> which returns <MAC ADDRESS of IP ADDRESS>

6. gcc can't find libc.so.4

7. dynamic ip address - how to get to know my ip address?

8. Lost passwords and Data

9. IP Masquerading with IP Address and Mac Address Restrictions

10. security/network impact with aliase ip addresses

11. Apache and ip address security based

12. I wanted to extract the Source IP address and Destination IP address from packets passing through bridge, Is IP address offset is fixed?

13. Binding a single IP Address to two different MAC addresses