draft-forte-dhc-passive-dad-00.txt - client ID support

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte
Dear all,

at the last IETF meeting it was decided that two main issues should have
been addressed for p-DAD. One was the amount of traffic introduced
between the AUC and DHCP server, the other issue was the support of the
client-ID instead of the MAC address.

Regarding the amount of traffic introduced between the AUC and the DHCP
server, we are currently taking some measurements so that later we can
show you some numbers.

For adding client-id support to the p-DAD we were thinking of the
following:
the AUC can create two tables, one is the table with {MAC, IP} pair that
we already have and it is built by listening to normal *non DHCP*
traffic; the second table would contain {DUID, MAC} pairs and it would
be built by listening to DHCP traffic*only*. In particular we might be
able to use DHCP_REQUESTs only. The two tables are independent. The
first one tells us which IPs are being used for which MAC, while the
second one tells us each MAC to which client ID it corresponds to. If
the AUC detects the same IP with two different MACs, it checks the
second table to see if the two MACs belong to the same client (that is
have the same DUID) or not. If they do, then the AUC will not send
anything to the DHCP server, otherwise it will as a duplicate IP address
might have occurred.
The packet format between AUC and DHCP server would be something like this:
_________________________
| Flag | ID (6 bytes) | IP address |

where flag indicates if the client-ID option is being used or not. In
the latter case we would have the normal scenario based on the MAC
address which is why we have the ID field 6 bytes long in the packet.
The IP address is the possible duplicate IP address.

All comments are as always wellcome.

-Andrea



_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Ted Lemon-2
That seems like a good idea in principal, but why not just use the
pre-existing table inside of the DHCP server?

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte
I am not sure I follow. Which pre-existing table are you referring to?
One of the goals of having the two tables in the AUC is that in this way
the traffic between AUC and DHCP server can be reduced by the AUC
looking at both tables and only then decide if to send a frame to the
server or not.

-Andrea


Ted Lemon wrote:

>That seems like a good idea in principal, but why not just use the
>pre-existing table inside of the DHCP server?
>  
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Ted Lemon-2
On Tuesday 22 November 2005 13:32, Andrea G Forte wrote:
> I am not sure I follow. Which pre-existing table are you referring to?
> One of the goals of having the two tables in the AUC is that in this way
> the traffic between AUC and DHCP server can be reduced by the AUC
> looking at both tables and only then decide if to send a frame to the
> server or not.

The problem with snooping on the network is that it means that you are going
to have an incomplete picture of what's going on.   In the case of ARP
caching, that's okay, because if you don't have the information in the cache,
you're no worse off than you otherwise would have been.   In the case of a
MAC address to client identifier map, though, if an entry in the map is
missing, you're going to report an address conflict to the DHCP server when
no address conflict exists.   So I think a potentially lossy cache doesn't
work in this case.

The more I think about this, the more it seems that it can't really work.  
The problem is that you need to have an accurate table mapping client
identifiers to MAC addresses.   But there is nowhere on the network where you
can get this table.   The reasons are as follows:

1. DHCP server can get MAC addresses.   But only if it's on the same wire as
the client; otherwise it doesn't see the wire MAC address of the client - it
sees the wire MAC address of the router that delivers the relayed packet.

2. Relay agent can get MAC addresses.   Okay, this is workable, but now you
have a custom relay agent that you have to write.

3. Not all media use MAC addresses.   No workaround for this, other than
declaring that PDAD doesn't work on such media.

4. Snoop.   This doesn't work because in practice you can't be sure of
successfully snooping every packet.

So I guess if you're willing to deploy special relay agents and you're willing
to say PDAD doesn't work on firewire or infiniband, you can make it work.  
It's probably a very reasonable line of research.   But I don't see it
turning into something that could be readily deployed in a production
environment, unless you can talk Cisco, Juniper, and all the other vendors
into updating their relay agents.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Bernie Volz (volz)
In reply to this post by Andrea G Forte
> 1. DHCP server can get MAC addresses.   But only if it's on
> the same wire as
> the client; otherwise it doesn't see the wire MAC address of
> the client - it
> sees the wire MAC address of the router that delivers the
> relayed packet.

Huh? The DHCP packets have the chaddr (and htype and hlen), so the DHCP
server always has the MAC.

Of course, that only works if there is a MAC address.

But ARP also only runs over Ethernet-like interfaces.

- Bernie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Ted Lemon
> Sent: Tuesday, November 22, 2005 4:01 PM
> To: Andrea G Forte
> Cc: [hidden email]
> Subject: Re: [dhcwg] draft-forte-dhc-passive-dad-00.txt -
> client ID support
>
> On Tuesday 22 November 2005 13:32, Andrea G Forte wrote:
> > I am not sure I follow. Which pre-existing table are you
> referring to?
> > One of the goals of having the two tables in the AUC is
> that in this way
> > the traffic between AUC and DHCP server can be reduced by the AUC
> > looking at both tables and only then decide if to send a
> frame to the
> > server or not.
>
> The problem with snooping on the network is that it means
> that you are going
> to have an incomplete picture of what's going on.   In the
> case of ARP
> caching, that's okay, because if you don't have the
> information in the cache,
> you're no worse off than you otherwise would have been.   In
> the case of a
> MAC address to client identifier map, though, if an entry in
> the map is
> missing, you're going to report an address conflict to the
> DHCP server when
> no address conflict exists.   So I think a potentially lossy
> cache doesn't
> work in this case.
>
> The more I think about this, the more it seems that it can't
> really work.  
> The problem is that you need to have an accurate table mapping client
> identifiers to MAC addresses.   But there is nowhere on the
> network where you
> can get this table.   The reasons are as follows:
>
> 1. DHCP server can get MAC addresses.   But only if it's on
> the same wire as
> the client; otherwise it doesn't see the wire MAC address of
> the client - it
> sees the wire MAC address of the router that delivers the
> relayed packet.
>
> 2. Relay agent can get MAC addresses.   Okay, this is
> workable, but now you
> have a custom relay agent that you have to write.
>
> 3. Not all media use MAC addresses.   No workaround for this,
> other than
> declaring that PDAD doesn't work on such media.
>
> 4. Snoop.   This doesn't work because in practice you can't
> be sure of
> successfully snooping every packet.
>
> So I guess if you're willing to deploy special relay agents
> and you're willing
> to say PDAD doesn't work on firewire or infiniband, you can
> make it work.  
> It's probably a very reasonable line of research.   But I
> don't see it
> turning into something that could be readily deployed in a production
> environment, unless you can talk Cisco, Juniper, and all the
> other vendors
> into updating their relay agents.
>
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte
In reply to this post by Ted Lemon-2
Please read inline comments.

Ted Lemon wrote:

>The problem with snooping on the network is that it means that you are going
>to have an incomplete picture of what's going on.   In the case of ARP
>caching, that's okay, because if you don't have the information in the cache,
>you're no worse off than you otherwise would have been.   In the case of a
>MAC address to client identifier map, though, if an entry in the map is
>missing, you're going to report an address conflict to the DHCP server when
>no address conflict exists.   So I think a potentially lossy cache doesn't
>work in this case.
>  
>
This is true. However, you have to keep in mind that the AUC just tells
the DHCP server which IPs are
currently in use and which ones might *potentially* be in conflict. It
is up to the DHCP server to make
the final decision. If the AUC finds an IP address in use for which
there is no entry in the MAC-client ID
table, it means that someone is using an IP address that has been
configured manually (as there was no
DHCP traffic for that MAC). The AUC will then inform the DHCP server
about this IP. If this IP has
not yet been assigned by the DHCP server, the server will put this IP in
the "not free" IP address pool so
that it does not get assigned later on; if this IP has legally been
assigned by the server and we have
somehow missed the DHCP traffic for that MAC, the server will either
just ignore the
frame from the AUC or inform the AUC about the false positive.

>The more I think about this, the more it seems that it can't really work.  
>The problem is that you need to have an accurate table mapping client
>identifiers to MAC addresses.   But there is nowhere on the network where you
>can get this table.   The reasons are as follows:
>
>1. DHCP server can get MAC addresses.   But only if it's on the same wire as
>the client; otherwise it doesn't see the wire MAC address of the client - it
>sees the wire MAC address of the router that delivers the relayed packet.
>  
>
Yes, the AUC on the DHCP server would not make much sense.

>2. Relay agent can get MAC addresses.   Okay, this is workable, but now you
>have a custom relay agent that you have to write.
>  
>
This is the way I have implemented it so far and it seems to be the best
fit. The AUC is a module that runs in
a separate thread of the existing ISC relay agent. It is very easy to
integrate in existing relay agents.

>3. Not all media use MAC addresses.   No workaround for this, other than
>declaring that PDAD doesn't work on such media.
>  
>
Or, perhaps, the DHCP server could inform the AUC about these particular
clients.

-Andrea

>4. Snoop.   This doesn't work because in practice you can't be sure of
>successfully snooping every packet.
>
>So I guess if you're willing to deploy special relay agents and you're willing
>to say PDAD doesn't work on firewire or infiniband, you can make it work.  
>It's probably a very reasonable line of research.   But I don't see it
>turning into something that could be readily deployed in a production
>environment, unless you can talk Cisco, Juniper, and all the other vendors
>into updating their relay agents.
>  
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Ted Lemon-2
In reply to this post by Bernie Volz (volz)
On Tuesday 22 November 2005 16:02, Bernie Volz (volz) wrote:
> Huh? The DHCP packets have the chaddr (and htype and hlen), so the DHCP
> server always has the MAC

It's true that the DHCP server does have the claimed MAC address.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Barr Hibbs
In reply to this post by Andrea G Forte

I've been thinking about this for the last few days and
suspect that the capability to detect duplicate addresses
might be generally useful to more than just DHCP clients and
servers.

That said, I'm pretty sure that the AUC proposed in Andrea's
draft is roughly the equivalent of a DHCP relay agent:
something that most likely will be implemented as an
embedded component of other network equipment such as
routers or switches (only for network segments without a
router.)

At this point, a DHCP server and relay agent each have some
knowledge of a client based on what they know to be
absolutely correct (the gateway address from which a packet
is received and the network address assigned by the server,)
and what they reasonably assume to be correct (the client
identification in one of several possible forms, including
none, and the client hardware address, although there are a
few troubling cases.)

Presumably a relay agent would, unless compromised, always
accurately report what it knew of IP address usage
associated with client identity, so in the simple case, only
the nearest relay agent need be queried during duplicate
address detection by the server.

In the more general case, a trust relationship needs to be
established between the server and all relay agents, similar
to RFC 3118 authentication, for a number of reasons
including (1) verified identity of the server and relay
agents, (2) reasonably guaranteed integrity of the
address-identity association, and (3) reasonable prevention
of spoofing and some other attacks.

This would require that a server determine (mostly
passively, but perhaps by some mechanism to actively poll
the network) the existence of relay agents.  A server could
then multi-cast queries to the relay agents when probing to
see if an address about to be assigned is known to be in
use, or direct specific inquiries to the relay agent(s)
closest to the last known client holding an address lease to
determine if the client identity-IP address association is
still in use.

In short, I think that Andrea's proposal should be folded
into the definition of a relay agent, that some additional
server-to-relay agent functionality may be required, and
that authenticated message exchange is probably needed to
prevent malicious behavior.

--Barr


> -----Original Message-----
>
> I am not sure I follow. Which pre-existing table
> are you referring to?
> One of the goals of having the two tables in the
> AUC is that in this way
> the traffic between AUC and DHCP server can be
> reduced by the AUC
> looking at both tables and only then decide if to
> send a frame to the
> server or not.
>
> -Andrea
>
>
> Ted Lemon wrote:
>
> >That seems like a good idea in principal, but
> why not just use the
> >pre-existing table inside of the DHCP server?
> >
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Barr Hibbs
In reply to this post by Ted Lemon-2

The appropriate question is whether or not media such as
Firewire and InifiniBand are or will be in sufficient use
along with a DHCP server such that this is a show-stopper?

If such media types are an insignificant or minor part of
our networks, maybe the most straightforward thing is to
declare duplicate address detection not possible for those
media types.

If, on the other hand, the occurrence of such media is
expected to be significant or dominant, then it's back to
the drawing board.

--Barr


> -----Original Message-----
>
> Not all media use MAC addresses.   No
> workaround for this, other than
> declaring that PDAD doesn't work on such media.
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte
In reply to this post by Barr Hibbs
Please read the inline comments.
Thank you.

>In the more general case, a trust relationship needs to be
>established between the server and all relay agents, similar
>to RFC 3118 authentication, for a number of reasons
>including (1) verified identity of the server and relay
>agents, (2) reasonably guaranteed integrity of the
>address-identity association, and (3) reasonable prevention
>of spoofing and some other attacks.
>  
>
We did not consider much security issues in our draft. This choice was
taken because
we felt that there were bigger security problems in the general DHCP
framework. So,
just fixing the ones related to our draft only, would have not helped much.
However I agree. Security is a big concern and all the suggestions
expressed above
should be taken into serious consideration.

>This would require that a server determine (mostly
>passively, but perhaps by some mechanism to actively poll
>the network) the existence of relay agents.  A server could
>then multi-cast queries to the relay agents when probing to
>see if an address about to be assigned is known to be in
>use, or direct specific inquiries to the relay agent(s)
>closest to the last known client holding an address lease to
>determine if the client identity-IP address association is
>still in use.
>  
>
I do not understand why multicast would be of any use. The DHCP server
already knows
from which Relay Agent a request is coming from, so it would ask to that
Relay Agent only.
Also, I do not see the advantages of a query mechanism as opposed to the
mechanism we propose.
As we will show with some measurements, the load between AUC and DHCP
server is very low.
Quering a Relay Agent (RA) per each DHCP transaction seems like it might
actually introduce
more traffic than with the proposed approach depending on what kind of
information the response
to these queries would contain. Also, a duplicate or unauthorized
address being in use would not be
discovered by the DHCP server until a query takes place, even though the
AUC/RA might
have known for quite some time. This might be important if in the future
we think of ways to
address the problem of how to deal with unauthorized users just taking
an IP address they like.

-Andrea

>In short, I think that Andrea's proposal should be folded
>into the definition of a relay agent, that some additional
>server-to-relay agent functionality may be required, and
>that authenticated message exchange is probably needed to
>prevent malicious behavior.
>
>--Barr
>
>
>  
>
>>-----Original Message-----
>>
>>I am not sure I follow. Which pre-existing table
>>are you referring to?
>>One of the goals of having the two tables in the
>>AUC is that in this way
>>the traffic between AUC and DHCP server can be
>>reduced by the AUC
>>looking at both tables and only then decide if to
>>send a frame to the
>>server or not.
>>
>>-Andrea
>>
>>
>>Ted Lemon wrote:
>>
>>    
>>
>>>That seems like a good idea in principal, but
>>>      
>>>
>>why not just use the
>>    
>>
>>>pre-existing table inside of the DHCP server?
>>>
>>>      
>>>
>
>
>_______________________________________________
>dhcwg mailing list
>[hidden email]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>  
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Barr Hibbs
[Barr]
> >In the more general case, a trust relationship
> >needs to be established between the server and all
> >relay agents, similar to RFC 3118 authentication,
> >for a number of reasons including (1) verified
> >identity of the server and relay agents,
> >(2) reasonably guaranteed integrity of the
> >address-identity association, and (3) reasonable
> >prevention of spoofing and some other attacks.
> >
[Andrea]
> We did not consider much security issues in our
> draft. This choice was taken because we felt that
> there were bigger security problems in the general
> DHCP framework.  So, just fixing the ones related
> to our draft only would have not helped much.
> However I agree.  Security is a big concern and
> all the suggestions  expressed above should be
> taken into serious consideration.
>
...I am aware of a few areas in which authenticated
DHCP transactions are seen as a true business
requirement, so revisiting 3118 and the operation of
relay agents may be the logical next step.  When I
wrote the above reply the potential for spoofing and
other attacks (point 3) was in my mind.


[Barr]

> >This would require that a server determine (mostly
> >passively, but perhaps by some mechanism to actively
> >poll the network) the existence of relay agents.  A
> >server could then multi-cast queries to the relay
> >agents when probing to see if an address about to be
> >assigned is known to be in use, or direct specific
> >inquiries to the relay agent(s) closest to the last
> >known client holding an address lease to determine
> >if the client identity-IP address association is
> >still in use.
> >
[Andrea]

> I do not understand why multicast would be of any
> use.  The DHCP server already knows from which Relay
> Agent a request is coming from, so it would ask to
> that Relay Agent only.  Also, I do not see the
> advantages of a query mechanism as opposed to the
> mechanism we propose.  As we will show with some
> measurements, the load between AUC and DHCP server
> is very low.  Querying a Relay Agent (RA) per each
> DHCP transaction seems like it might actually
> introduce more traffic than with the proposed
> approach depending on what kind of information the
> response to these queries would contain. Also, a
> duplicate or unauthorized address being in use
> would not be discovered by the DHCP server until a
> query takes place, even though the AUC/RA might
> have known for quite some time.  This might be
> important if in the future we think of ways to
> address the problem of how to deal with
> unauthorized users just taking an IP address they
> like.
>
Yes, the server knows from which relay agent a
message is received, but that is the NEAREST agent
to the server -- only the agent nearest to the client
(if this functionality is integrated into a router,
for instance) would be aware of the client's use of
an address if not assigned by a server.  Since there
is no way for a server to have a priori information
about where in the interconnected network segments a
potentially rogue user of an address is located,
multicasting a query to the known routers is a
reasonable way to get the coverage desired.  This is
certainly no worse than broadcasting an ICMP ECHO to
all subnets -- recalling that many operators
intentionally disable PINGs because of abuse
potential, and where PINGs are permitted, a
potentially lengthy timeout period must elapse
before non-use can be assumed -- and may be a less
burdensome process overall.

As Ted pointed out, this is a non-trivial
modification to the relay agent functionality, but
there are potential benefits:  (1) broadcast ICMP
ECHO and reply traffic is eliminated, at least for
DHCP, (2) ARP messages originating in a DHCP client
probably can be eliminated as well, (3) by
eliminating the ICMP and ARP message [exchanges] the
total elapsed time for address lease acquisition may
be significantly reduced, with benefits for wireless
operators, (4) the availability of associations
between hardware address (and possibly, client
identification) and IP address outside of the DHCP
server may be useful in other contexts such as
network management and inventory or AAA and intrusion
detection.

>From the perspectives of servers and clients, the
changes are straightforward:  in place of ICMP ECHO
probing, the server queries the AUC/relay agents;  a
client simply eliminates ARP probing, trusting that
the offered address is unique because of a strong
trust relationship between DHCP servers and AUC/relay
agents.

Of course, collisions still can occur, either from
innocent use of a fixed address or with  malicious
intent.  With the AUC/relay agent functionality
integrated into routers (and possibly switches) it
should be possible to detect nearly all duplicates.

--Barr


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte
[Barr]

>Yes, the server knows from which relay agent a
>message is received, but that is the NEAREST agent
>to the server -- only the agent nearest to the client
>(if this functionality is integrated into a router,
>for instance) would be aware of the client's use of
>an address if not assigned by a server.  Since there
>is no way for a server to have a priori information
>about where in the interconnected network segments a
>potentially rogue user of an address is located,
>multicasting a query to the known routers is a
>reasonable way to get the coverage desired.  This is
>certainly no worse than broadcasting an ICMP ECHO to
>all subnets -- recalling that many operators
>intentionally disable PINGs because of abuse
>potential, and where PINGs are permitted, a
>potentially lengthy timeout period must elapse
>before non-use can be assumed -- and may be a less
>burdensome process overall.
>  
>
[Andrea]
We know exactly from which Relay Agent/network segment the request came
from (or where a rogue user is located). Usually the DHCP server looks
at the
'giaddr' field to tell from which Relay Agent the request is coming
from. The
'giaddr' field contains the IP address of the Relay Agent nearest to the
*client* requesting the IP address.
 From RFC 3046:
" [...] the relay agent SHALL forward any received DHCP packet
   with a valid non-zero giaddr WITHOUT adding any relay agent options.
   Per RFC 2131, it shall also NOT modify the giaddr value. "

Also, I do not see why the AUC can't just send the information directly
to the DHCP server without involving any Relay Agent.

[Barr]

>As Ted pointed out, this is a non-trivial
>modification to the relay agent functionality, but
>there are potential benefits:  (1) broadcast ICMP
>ECHO and reply traffic is eliminated, at least for
>DHCP, (2) ARP messages originating in a DHCP client
>probably can be eliminated as well, (3) by
>eliminating the ICMP and ARP message [exchanges] the
>total elapsed time for address lease acquisition may
>be significantly reduced, with benefits for wireless
>operators, (4) the availability of associations
>between hardware address (and possibly, client
>identification) and IP address outside of the DHCP
>server may be useful in other contexts such as
>network management and inventory or AAA and intrusion
>detection.
>  
>
[Andrea]
In my previous email I was trying to explain that if we think to address
problems such as intrusion detection, we should use a more responsive
mechanism than a query based one. In this case, having the AUC send
packets to the server when some condition occurs (i.e. unauthorized
IP address being used), might be better.

-Andrea


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Barr Hibbs

> -----Original Message-----

> [Andrea]
> We know exactly from which Relay Agent/network
> segment the request came from (or where a rogue
> user is located). Usually the DHCP server looks
> at the 'giaddr' field to tell from which Relay
> Agent the request is coming from.  The 'giaddr'
> field contains the IP address of the Relay Agent
> nearest to the *client* requesting the IP address.
> From RFC 3046:
> " [...] the relay agent SHALL forward any
> received DHCP packet with a valid non-zero giaddr
> WITHOUT adding any relay agent options.  Per RFC
> 2131, it shall also NOT modify the giaddr value."
>
> Also, I do not see why the AUC can't just send
> the information directly to the DHCP server
> without involving any Relay Agent.
>

[Barr]
I certainly see the validity of a host performing a
single dedicated function, tracking IP addresses
actually in use along with some client identifier,
in detecting duplicate addresses in use, but as a
practical matter I believe the functionality will
be implemented in a router that also implements the
functionality of a relay agent.

At the risk of going down a giant rat hole, there is
some troubling language in RFC 3046, specifically,
"...valid non-zero giaddr...."  How is the validity
of the received giaddr validated?

I assert that the AUC would have the same problem of
being validated as a legitimate source of warnings
about potentially duplicated IP addresses.

That is only to say that my opinion is that we must
solve the security issues first.  Of course, I will
continue to support integration of the AUC and relay
agent functionality because I believe that is a
natural pairing.


> [Andrea]
> In my previous email I was trying to explain that
> if we think to address problems such as intrusion
> detection, we should use a more responsive
> mechanism than a query based one.  In this case,
> having the AUC send packets to the server when
> some condition occurs (i.e. unauthorized
> IP address being used), might be better.
>

[Barr]
We probably agree about more than this exchange may
indicate, but I dispute the notion that having the
AUC send packets on each occurrence of some condition
of interest occurs would be better.  Taking the
example of an IP address being used without having
seen a DHCP protocol exchange could easily be
harmless -- many hosts do not have address leases,
utilizing fixed addresses.  Typically gateways,
servers, various managed devices, and printers do
not use either BOOTP or DHCP.  The only way to avoid
false reports would be to provide the AUC with
network configuration information, and as it would
of necessity be different from BOOTP/DHCP server
configuration, there is the classic problem of
consistency with which to contend.  Additionally,
having the AUC push announcements of detected events
towards the DHCP server requires potentially a very
significant change in server operation, not just to
receive and understand the notifications, but also
to deal with the possible loss of such messages (if
using UDP) or the loss of a connection (if using TCP.)

While I think that the functionality of the AUC may
very well be a useful tool for intrusion detection or
to supplement AAA and network management capabilities
I also assert that a growing list of network services
receiving pushed announcements could easily turn into
its own denial of service attack by a rogue host
intentionally spoofing many different MAC addresses
and IP address associations.

So, we have a number of things to work out, from the
basic philosophy of how to better perform duplicate
address detection, to securing the mechanism, to
how the functionality might be implemented.

I'm going to be totally inaccessible for e-mail until
December 4, so don't take my lack of response during
the interim as lack of interest or acquiescing to your
well-mounted arguments.

--Barr


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte

>>[Andrea]
>>We know exactly from which Relay Agent/network
>>segment the request came from (or where a rogue
>>user is located). Usually the DHCP server looks
>>at the 'giaddr' field to tell from which Relay
>>Agent the request is coming from.  The 'giaddr'
>>field contains the IP address of the Relay Agent
>>nearest to the *client* requesting the IP address.
>>>From RFC 3046:
>>" [...] the relay agent SHALL forward any
>>received DHCP packet with a valid non-zero giaddr
>>WITHOUT adding any relay agent options.  Per RFC
>>2131, it shall also NOT modify the giaddr value."
>>
>>Also, I do not see why the AUC can't just send
>>the information directly to the DHCP server
>>without involving any Relay Agent.
>>
>>    
>>
>
>[Barr]
>I certainly see the validity of a host performing a
>single dedicated function, tracking IP addresses
>actually in use along with some client identifier,
>in detecting duplicate addresses in use, but as a
>practical matter I believe the functionality will
>be implemented in a router that also implements the
>functionality of a relay agent.
>  
>
[Andrea]
Yes I agree, as was pointed out in the draft, the natural place for the
AUC would be
on a router and in particular on a relay agent. In our current
implementation
the AUC is part of the relay agent. In any event this does not prevent
the AUC
from talking directly to the DHCP server.

>At the risk of going down a giant rat hole, there is
>some troubling language in RFC 3046, specifically,
>"...valid non-zero giaddr...."  How is the validity
>of the received giaddr validated?
>
>I assert that the AUC would have the same problem of
>being validated as a legitimate source of warnings
>about potentially duplicated IP addresses.
>
>That is only to say that my opinion is that we must
>solve the security issues first.  Of course, I will
>continue to support integration of the AUC and relay
>agent functionality because I believe that is a
>natural pairing.
>  
>
[Andrea]
I think this is a bigger issue. The problem is not to secure the AUC, but
to secure the whole DHCP infrastructure. The AUC does not
introduce any new vulnerability by itself. The vulnerabilities that are
present
are there because of everything else not being secure.

>  
>
>>[Andrea]
>>In my previous email I was trying to explain that
>>if we think to address problems such as intrusion
>>detection, we should use a more responsive
>>mechanism than a query based one.  In this case,
>>having the AUC send packets to the server when
>>some condition occurs (i.e. unauthorized
>>IP address being used), might be better.
>>
>>    
>>
>
>[Barr]
>We probably agree about more than this exchange may
>indicate, but I dispute the notion that having the
>AUC send packets on each occurrence of some condition
>of interest occurs would be better.  Taking the
>example of an IP address being used without having
>seen a DHCP protocol exchange could easily be
>harmless -- many hosts do not have address leases,
>utilizing fixed addresses.  Typically gateways,
>servers, various managed devices, and printers do
>not use either BOOTP or DHCP.  The only way to avoid
>false reports would be to provide the AUC with
>network configuration information, and as it would
>of necessity be different from BOOTP/DHCP server
>configuration, there is the classic problem of
>consistency with which to contend.  Additionally,
>having the AUC push announcements of detected events
>towards the DHCP server requires potentially a very
>significant change in server operation, not just to
>receive and understand the notifications, but also
>to deal with the possible loss of such messages (if
>using UDP) or the loss of a connection (if using TCP.)
>  
>
[Andrea]
False positives sent by the AUC are not that critical. The AUC just sends a
warning to the DHCP server saying "I am detecting something potentially
irregular", the DHCP server then takes a decision based on the AUC
reports and on its lease/configuration file. The DHCP server will be aware
of static IPs used in the IP pool it manages (printers, servers, etc).
One of the thing to worry about might be the extra traffic between the AUC
and the DHCP server due to false positives. This traffic however would be
very small and it would occur only at the AUC's table expiration time.
Furthermore, false positives triggered by the AUC could easily be corrected
by the DHCP server. When a false positive is detected by the DHCP server,
 then the server could send a packet to the AUC to inform it to ignore a
particular IP address for a longer time, that is, the AUC would set a
longer
expiration time for that address in its table.
Overhead for a query-based mechanism and pushing mechanism would be
about the same. However, the pushing mechanism would be more responsive
and also it would inform the DHCP server about addresses in use "out of
band" and
not during the address acquisition process. Performing this kind of task
*during* the
assignement process, introduces unecessary delay, as small as it might
be. This is
particularly critical in mobile environments where clients need to
acquire a new IP
as fast as possible.

Either model is reasonable, I guess, it depends on how much logic
we want to put on the AUC and how much we want to add to the DHCP server.
There is a tradeoff between performances and implementation and we need to
decide which one would make more sense.

Having a secure TPC connection between AUC and DHCP server is
something quite useful in terms of both security and packet loss.

At this stage, we wanted to consider the AUC for DAD purposes and not
really for intrusion detection. Intrusion detection introduces a whole new
set of problems. It would be very interesting though to see how the
present mechanism might be extended for intrusion detection. All I am
saying is that we should probably go one step at the time.

>While I think that the functionality of the AUC may
>very well be a useful tool for intrusion detection or
>to supplement AAA and network management capabilities
>I also assert that a growing list of network services
>receiving pushed announcements could easily turn into
>its own denial of service attack by a rogue host
>intentionally spoofing many different MAC addresses
>and IP address associations.
>  
>
[Andrea]
In my opinion, the case of MAC spoofing is a more general problem. In such
a case we would have to worry about bigger possible damage like the
exhaustion of the IP pool which would also last past the attack until the
leases expire.

>So, we have a number of things to work out, from the
>basic philosophy of how to better perform duplicate
>address detection, to securing the mechanism, to
>how the functionality might be implemented.
>
>I'm going to be totally inaccessible for e-mail until
>December 4, so don't take my lack of response during
>the interim as lack of interest or acquiescing to your
>well-mounted arguments.
>  
>

Thank you for all of your comments. This exchange of ideas is making all
of this much
more interesting.

-Andrea

>--Barr
>
>
>_______________________________________________
>dhcwg mailing list
>[hidden email]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>  
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Barr Hibbs

sorry to have taken so long to reply to you, Andrea....

comments are in-line....

--Barr


> -----Original Message-----
> From: Andrea G Forte
> Sent: Monday, December 05, 2005 10:00
>
> >>[Andrea]
> >>We know exactly from which Relay Agent/network
> >>segment the request came from (or where a rogue
> >>user is located). Usually the DHCP server looks
> >>at the 'giaddr' field to tell from which Relay
> >>Agent the request is coming from.  The 'giaddr'
> >>field contains the IP address of the Relay Agent
> >>nearest to the *client* requesting the IP address.
> >>
> >>>From RFC 3046:
> >>" [...] the relay agent SHALL forward any
> >>received DHCP packet with a valid non-zero giaddr
> >>WITHOUT adding any relay agent options.  Per RFC
> >>2131, it shall also NOT modify the giaddr value."
> >>
> >>Also, I do not see why the AUC can't just send
> >>the information directly to the DHCP server
> >>without involving any Relay Agent.
> >>
>
...I really am biased against adding another server to be
administered, especially another physical server (network
host.)  Obviously, combining the functions in another,
existing device on the network still requires
administration, but as you've noted below, the functionality
does work pretty well for you in a relay agent.


> >[Barr]
> >I certainly see the validity of a host performing a
> >single dedicated function, tracking IP addresses
> >actually in use along with some client identifier,
> >in detecting duplicate addresses in use, but as a
> >practical matter I believe the functionality will
> >be implemented in a router that also implements the
> >functionality of a relay agent.
> >
> [Andrea]
> Yes I agree, as was pointed out in the draft, the
> natural place for the AUC would be on a router
> and in particular on a relay agent.  In our current
> implementation the AUC is part of the relay agent.
> In any event this does not prevent the AUC from
> talking directly to the DHCP server.
>
...no matter how or where the proposed functionality is
placed, there will be either protocol changes or a new
protocol.  As I think about this, your position that solving
the general problem of DHCP security is certainly one of the
fundamental issues the WG needs to address, but until we
have made some progress on DHCP security, including a
revisit to authentication, I'd rather not add a new protocol
for the servers to process, nor increase message traffic
during address assignment.  Does this mean I'm interested in
stepping up to the plate again to work on these issues?
Yes, definitely.


> >At the risk of going down a giant rat hole, there is
> >some troubling language in RFC 3046, specifically,
> >"...valid non-zero giaddr...."  How is the validity
> >of the received giaddr validated?
> >
> >I assert that the AUC would have the same problem of
> >being validated as a legitimate source of warnings
> >about potentially duplicated IP addresses.
> >
> >That is only to say that my opinion is that we must
> >solve the security issues first.  Of course, I will
> >continue to support integration of the AUC and relay
> >agent functionality because I believe that is a
> >natural pairing.
> >
> [Andrea]
> I think this is a bigger issue. The problem is
> not to secure the AUC, but to secure the whole DHCP
> infrastructure. The AUC does not introduce any new
> vulnerability by itself. The vulnerabilities that are
> present are there because of everything else not
> being secure.
>
...well, yes and no...  a rogue relay agent can no more
easily be detected than a rogue AUC, but because the relay
agent is so simple in function, it's pretty hard to design a
very effective network attack using one (ignoring the
obvious case of connecting a spurious network segment.)  A
rogue AUC could have a much more widespread impact on the
network.


> >>[Andrea]
> >>In my previous email I was trying to explain that
> >>if we think to address problems such as intrusion
> >>detection, we should use a more responsive
> >>mechanism than a query based one.  In this case,
> >>having the AUC send packets to the server when
> >>some condition occurs (i.e. unauthorized
> >>IP address being used), might be better.
> >>
> >
> >[Barr]
> >We probably agree about more than this exchange may
> >indicate, but I dispute the notion that having the
> >AUC send packets on each occurrence of some condition
> >of interest occurs would be better.  Taking the
> >example of an IP address being used without having
> >seen a DHCP protocol exchange could easily be
> >harmless -- many hosts do not have address leases,
> >utilizing fixed addresses.  Typically gateways,
> >servers, various managed devices, and printers do
> >not use either BOOTP or DHCP.  The only way to avoid
> >false reports would be to provide the AUC with
> >network configuration information, and as it would
> >of necessity be different from BOOTP/DHCP server
> >configuration, there is the classic problem of
> >consistency with which to contend.  Additionally,
> >having the AUC push announcements of detected events
> >towards the DHCP server requires potentially a very
> >significant change in server operation, not just to
> >receive and understand the notifications, but also
> >to deal with the possible loss of such messages (if
> >using UDP) or the loss of a connection (if using TCP.)
> >
> [Andrea]
> False positives sent by the AUC are not that
> critical. The AUC just sends a warning to the DHCP
> server saying "I am detecting something potentially
> irregular", the DHCP server then takes a decision
> based on the AUC reports and on its lease/
> configuration file. The DHCP server will be aware
> of static IPs used in the IP pool it manages
> (printers, servers, etc). One of the thing to worry
> about might be the extra traffic between the AUC
> and the DHCP server due to false positives. This
> traffic however would be very small and it would
> occur only at the AUC's table expiration time.
> Furthermore, false positives triggered by the AUC
> could easily be corrected by the DHCP server. When
> a false positive is detected by the DHCP server,
> then the server could send a packet to the AUC
> to inform it to ignore a particular IP address for
> a longer time, that is, the AUC would set a longer
> expiration time for that address in its table.
> Overhead for a query-based mechanism and pushing
> mechanism would be about the same. However, the
> pushing mechanism would be more responsive and
> also it would inform the DHCP server about
> addresses in use "out of band" and not during the
> address acquisition process. Performing this kind
> of task *during* the assignment process
> introduces unnecessary delay, as small as it might
> be. This is particularly critical in mobile
> environments where clients need to acquire a new
> IP as fast as possible.
>
...I very much disagree about the effect of false positives.
My biggest concern is the potential for a denial of service
attack from a rogue AUC that simply tells the DHCP server
(and any other device that is listening to the potential
conflict reports that EVERY MAC address in use on a network
segment is a duplicate.  Because of load-balancing and
failover, that attack could quickly spread to multiple
servers and then the entire network.  Yet another example of
why we really do need to address general DHCP security soon.

If we did have a secure DHCP protocol, with detection and
authentication of not just clients, but also relay agents
and AUCs, then I don't think there is that much difference
in the performance of push vs. pull strategies.  True,
querying an AUC during the address assignment process can
slow it, but unlike issuing an ICMP ECHO and waiting for
timeout, the DHCP server could invoke a strategy that polled
the AUCs periodically when the server is idle, set a
lifetime for the data collected, and only query the AUC
during the offer process if its usage information is missing
or out of date.

On the other hand, an implementation of the two-message
protocol exchange would presumably not wish to wait for any
sort of PING or ARP response, so having the AUC push
potential conflicts to the server would be extremely useful.

After rattling on this afternoon responding to you, I think
that we've got several areas to discuss at length before
settling on any solution.


> Either model is reasonable, I guess, it depends
> on how much logic we want to put on the AUC and
> how much we want to add to the DHCP server.
> There is a tradeoff between performances and
> implementation and we need to decide which one
> would make more sense.
>
> Having a secure TPC connection between AUC and
> DHCP server is something quite useful in terms
> of both security and packet loss.
>
...your point is well-taken, and it raises for me the
possibility of reexamining the operation of relay agents:  a
TCP connection between DHCP servers and relay agents might
be the way to secure that path.


> At this stage, we wanted to consider the AUC for
> DAD purposes and not really for intrusion
> detection. Intrusion detection introduces a
> whole new set of problems. It would be very
> interesting though to see how the present
> mechanism might be extended for intrusion
> detection. All I am saying is that we should
> probably go one step at the time.
>
...yes, I am just observing that DAD and ID are very similar
in this specific context, that of gaining network
connectivity.


> >While I think that the functionality of the AUC may
> >very well be a useful tool for intrusion detection or
> >to supplement AAA and network management capabilities
> >I also assert that a growing list of network services
> >receiving pushed announcements could easily turn into
> >its own denial of service attack by a rogue host
> >intentionally spoofing many different MAC addresses
> >and IP address associations.
> >
> [Andrea]
> In my opinion, the case of MAC spoofing is a more
> general problem. In such a case we would have to worry
> about bigger possible damage like the exhaustion of
> the IP pool which would also last past the attack
> until the leases expire.
>
...as Ted pointed out at the last WG meeting, there are
several different types of media where we cannot expect a
MAC address, so we have one more general problem to be
addressed about DHCP security and authentication.


> >So, we have a number of things to work out, from the
> >basic philosophy of how to better perform duplicate
> >address detection, to securing the mechanism, to
> >how the functionality might be implemented.
> >

*Snip!*


> Thank you for all of your comments. This exchange
> of ideas is making all of this much more interesting.
>
> -Andrea
>
...definitely exercising my grey matter a bit!

--Barr


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: draft-forte-dhc-passive-dad-00.txt - client ID support

Andrea G Forte
Barr Hibbs wrote:

>sorry to have taken so long to reply to you, Andrea....
>
>comments are in-line....
>
>--Barr
>  
>
Gald to see you are back Barr. Hope you had a good Xmas and new year.
As usual, comments are inline.

-Andrea

>>>>[Andrea]
>>>>We know exactly from which Relay Agent/network
>>>>segment the request came from (or where a rogue
>>>>user is located). Usually the DHCP server looks
>>>>at the 'giaddr' field to tell from which Relay
>>>>Agent the request is coming from.  The 'giaddr'
>>>>field contains the IP address of the Relay Agent
>>>>nearest to the *client* requesting the IP address.
>>>>
>>>>>From RFC 3046:
>>>>" [...] the relay agent SHALL forward any
>>>>received DHCP packet with a valid non-zero giaddr
>>>>WITHOUT adding any relay agent options.  Per RFC
>>>>2131, it shall also NOT modify the giaddr value."
>>>>
>>>>Also, I do not see why the AUC can't just send
>>>>the information directly to the DHCP server
>>>>without involving any Relay Agent.
>>>>
>>>>        
>>>>
>[Barr]
>...I really am biased against adding another server to be
>administered, especially another physical server (network
>host.)  Obviously, combining the functions in another,
>existing device on the network still requires
>administration, but as you've noted below, the functionality
>does work pretty well for you in a relay agent.
>  
>
[Andrea]
Sorry about the confusion. Yes, we both agree that an AUC can be easily
integrated in
a Relay Agent (RA) and that this is the most natural place for it.
What I was trying to say in a rather confusing way is that the messages
that the AUC sends to the
DHCP server do not have to necessarely follow the same rules than normal
RA messages
have to follow. In particular, AUC messages can be directly sent to the
server without having
to go through other RAs (no relay necessary).

>>[Andrea]
>>I think this is a bigger issue. The problem is
>>not to secure the AUC, but to secure the whole DHCP
>>infrastructure. The AUC does not introduce any new
>>vulnerability by itself. The vulnerabilities that are
>>present are there because of everything else not
>>being secure.
>>
>>    
>>
>[Barr]
>...well, yes and no...  a rogue relay agent can no more
>easily be detected than a rogue AUC, but because the relay
>agent is so simple in function, it's pretty hard to design a
>very effective network attack using one (ignoring the
>obvious case of connecting a spurious network segment.)  A
>rogue AUC could have a much more widespread impact on the
>network.
>
>  
>
>[Barr]
>...I very much disagree about the effect of false positives.
>My biggest concern is the potential for a denial of service
>attack from a rogue AUC that simply tells the DHCP server
>(and any other device that is listening to the potential
>conflict reports that EVERY MAC address in use on a network
>segment is a duplicate.  Because of load-balancing and
>failover, that attack could quickly spread to multiple
>servers and then the entire network.  Yet another example of
>why we really do need to address general DHCP security soon.
>  
>
[Andrea]
Well, this is an issue that is already present today without any AUC.
Infact all you need
to do as a malicious user is to answer to any ICMP echo request when the
DAD procedure
is performed. This will cause DoS for that particular subnet as the
server will wrongly think that all
the possible IPs are in use.
I still think that the AUC is not adding any extra vulnerability. They
are all already there.
Once the problem of general DHCP security will be solved, AUC issues
will automatically be
solved as well.

>[Barr]
>If we did have a secure DHCP protocol, with detection and
>authentication of not just clients, but also relay agents
>and AUCs, then I don't think there is that much difference
>in the performance of push vs. pull strategies.  True,
>querying an AUC during the address assignment process can
>slow it, but unlike issuing an ICMP ECHO and waiting for
>timeout, the DHCP server could invoke a strategy that polled
>the AUCs periodically when the server is idle, set a
>lifetime for the data collected, and only query the AUC
>during the offer process if its usage information is missing
>or out of date.
>  
>
[Andrea]
Yes, but then you might miss IPs that have been "taken" in between
updates (in between polls) and this
might cause duplicate address. One solution to this would be to make the
lifetime of the collected data
very short, this however would introduce too much overhead and would
significantly degrade the performance of the
query mechanism that would then loose its purpose.

>>[Andrea]
>>Either model is reasonable, I guess, it depends
>>on how much logic we want to put on the AUC and
>>how much we want to add to the DHCP server.
>>There is a tradeoff between performances and
>>implementation and we need to decide which one
>>would make more sense.
>>
>>Having a secure TPC connection between AUC and
>>DHCP server is something quite useful in terms
>>of both security and packet loss.
>>
>>    
>>
>[Barr]
>...your point is well-taken, and it raises for me the
>possibility of reexamining the operation of relay agents:  a
>TCP connection between DHCP servers and relay agents might
>be the way to secure that path.
>  
>
[Andrea]
We seem to agree here. This would also take care of rogue AUCs/RAs.

>>[Andrea]
>>In my opinion, the case of MAC spoofing is a more
>>general problem. In such a case we would have to worry
>>about bigger possible damage like the exhaustion of
>>the IP pool which would also last past the attack
>>until the leases expire.
>>
>>    
>>
>[Barr]
>...as Ted pointed out at the last WG meeting, there are
>several different types of media where we cannot expect a
>MAC address, so we have one more general problem to be
>addressed about DHCP security and authentication.
>  
>
[Andrea]
I do not know the details about this kind of devices and how the DHCP server
behaves with them. However, I would think that there has to be some kind
of Client
ID for such devices ( I am thinking about draft 3315id).

>>>[Barr]
>>>So, we have a number of things to work out, from the
>>>basic philosophy of how to better perform duplicate
>>>address detection, to securing the mechanism, to
>>>how the functionality might be implemented.
>>>
Yes, agree.



Thanks again,
-Andrea


>>
>>    
>>
>...definitely exercising my grey matter a bit!
>
>--Barr
>  
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: draft-forte-dhc-passive-dad-00.txt - client ID support

Barr Hibbs

Andrea--

this is the most stimulating tech exchange I've had in a
while:  it's forcing me to consider a number of different
issues that we've let slide because no one has a great
proposal for how to simply administer the identification and
authentication of DHCP servers, relay agents, and clients.

I've trimmed the original message text a bit to keep this
from growing totally out of hand.

--Barr

> -----Original Message-----
> From: Andrea G. Forte
> Sent: Tuesday, January 10, 2006 11:36
>
*Snip!*

>
> >[Barr]
> >...I really am biased against adding another server to be
> >administered, especially another physical server (network
> >host.)  Obviously, combining the functions in another,
> >existing device on the network still requires
> >administration, but as you've noted below, the
> functionality does work pretty well for you in a relay
> >agent.
> >
> [Andrea]
> Sorry about the confusion. Yes, we both agree that an
> AUC can be easily integrated in a Relay Agent (RA) and
> that this is the most natural place for it.
> What I was trying to say in a rather confusing way is
> that the messages that the AUC sends to the DHCP server
> do not have to necessarily follow the same rules that
> normal RA messages have to follow. In particular, AUC
> messages can be directly sent to the server without
> having to go through other RAs (no relay necessary).
>
[Barr]
I'm glad you clarified that.  Your point about possibly
using a TCP session between the DHCP server and the
AUC/relay agent implied as much, and I was never at all
clear that message exchanges between the two are [in the
steady state] between hosts with known IP addresses.


> >>[Andrea]
> >>I think this is a bigger issue. The problem is
> >>not to secure the AUC, but to secure the whole DHCP
> >>infrastructure.

*Snip!*

> >[Barr]

*Snip!*

> >My biggest concern is the potential for a denial
> >of service attack from a rogue AUC that simply tells
> >the DHCP server (and any other device that is
> >listening to the potential conflict reports that
> >EVERY MAC address in use on a network segment is a
> >duplicate.

*Snip!*

> [Andrea]
> Well, this is an issue that is already present
> today without any AUC.

*Snip!*

> Once the problem of general DHCP security will
> be solved, AUC issues will automatically be
> solved as well.
>
[Barr]
Agreed.  We absolutely need to revisit the RFC3118 issues
that were raised about two years ago and see whether or not
there is a way out of the quagmire imposed by the base
assumptions that some external authority is always acting to
configure client and server authentication.

I've some ideas, but each of them has corresponding flaws
such that I'm not sure any of them are workable.


> >[Barr]
> >If we did have a secure DHCP protocol, with detection and
> >authentication of not just clients, but also relay agents
> >and AUCs, then I don't think there is that much
> >difference in the performance of push vs. pull
> >strategies.  True, querying an AUC during the address
> >assignment process can slow it, but unlike issuing an
ICMP
> >ECHO and waiting for timeout, the DHCP server could
invoke
> >a strategy that polled the AUCs periodically when the
> >server is idle, set a lifetime for the data collected,
and

> >only query the AUC during the offer process if its usage
> information is missing or out of date.
> >
> [Andrea]
> Yes, but then you might miss IPs that have been "taken"
> in between updates (in between polls) and this might
> cause duplicate address.  One solution to this would be
> to make the lifetime of the collected data very short,
> this however would introduce too much overhead and would
> significantly degrade the performance of the query
> mechanism that would then lose its purpose.
>
[Barr]
Choice of a strategy requires more discussion, but what I'm
suggesting is similar to the way that DNS operates, with the
TTL of query results essentially variable depending on
considerations not part of the actual message exchange.

Essentially, your proposal for a DAD function that is
[largely] separate from IP address assignment is a
well-considered attempt to improve the performance of DHCP
in a world where we are increasingly demanding instantaneous
connectivity for highly mobile devices.  Recall, however,
the original duplicate address detection methods employed in
DHCPv4 are only "best effort" procedures, relying on
essentially unreliable mechanisms (ICMP ECHO and ARP.)

When I think about the impact of a malicious host saying,
"Yes, that IP address is in use," to each and every ARP
request it almost seems as if we are fighting a lost cause.
While I suppose that a smart switch with DAD features might
notice that a single host [switch port] is claiming multiple
identities within an interval too short for legitimate
address assignment and shut off the port connected to the
offending host, at first thought such a mechanism would
require a stateful switch that listens to and is mindful of
address assignment messages and other traffic.


> >>[Andrea]
> >>Either model is reasonable, I guess, it depends
> >>on how much logic we want to put on the AUC and
> >>how much we want to add to the DHCP server.
> >>There is a tradeoff between performances and
> >>implementation and we need to decide which one
> >>would make more sense.
> >>
> >>Having a secure TPC connection between AUC and
> >>DHCP server is something quite useful in terms
> >>of both security and packet loss.
> >>
> >[Barr]
> >...your point is well-taken, and it raises for me the
> >possibility of reexamining the operation of relay
> >agents:  a TCP connection between DHCP servers and
> relay agents might be the way to secure that path.
> >
> [Andrea]
> We seem to agree here. This would also take care
> of rogue AUCs/RAs.
>
[Barr]
So, let me attempt a summary:  we concur that using a TCP
session between hosts that are generators and consumers of
DAD information is probably the way to go.


> >>[Andrea]
> >>In my opinion, the case of MAC spoofing is a more
> >>general problem.

*Snip!*

> >[Barr]
> >...as Ted pointed out at the last WG meeting, there are
> >several different types of media where we cannot expect a
> >MAC address, so we have one more general problem to be
> >addressed about DHCP security and authentication.
> >
> [Andrea]
> I do not know the details about these kind of devices and
> how the DHCP server behaves with them.  However, I would
> think that there has to be some kind of Client ID for
> such devices (I am thinking about draft 3315id).
>
[Barr]
yes, the discussion came up in the context of 3315-syle IDs,
but I'm not yet sure that we've got a handle on the entire
NIC/media problem.  Although only a small number of the
defined media types (HTYPE field) are actually in use, we
MUST NOT be fixed on an Ethernet-centric world.  At the very
least, we've got FireWire, USB, "Space" Ethernet, and
possibly HDMI with which to contend.

I'll assert right now that the explosion in consumer devices
with networking capabilities will definitely impact any
procedures we devise for duplicate address detection and
mitigation, if simply because we can expect collisions
between media implementations of different eras.




_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg