Subject: [dhcwg] Source address and source port problem in DHCP server

From: "Jitesh N Verma" <[email-masked]>
Date: Sat, 2 Aug 2003 18:36:19 +0530

Hi all,
Please read care fully, since the following text is 
bit confusing.

Background:
I have come across a relay agent (CISCO router),
which checks the source IP address of the server's
reply packet against the destination IP address
of the relayed request packet and discards the
reply packet if they do not match. 
If a DHCP relay agent relays a request to an alias
IP address (e.g.lan0:1 - 1.1.1.2), HP DHCP server
replies with primary IP address (lan0 - 1.1.1.1) as
the source IP address. If there is no alias IP address
configured for an interface, the DHCP server works fine.

Question:
Can somebody tell me if checking of the source address
of the reply packet with the destination address of the
relayed request packet by a DHCP relay agent OK? RFC
does not say anything on this issue. I want to know
who is not comploying with the RFC? Relay? Or the
server?

While trying to fix the source address problem in
DHCP server, I ran into similar problem with the
source port. I want to know if any implemettaion
of DHCP relay agent checks for the source port of
the reply packet with the destination port of the
relayed request packet.

If yes, is checking of source port of the reply
packet with the destination port of the relayed
request packet by the relay agent OK? Again RFC
does not say anything about the source port of
the reply packet from the server.

Can somebody tell me whether such checks on the
source port and address of the reply packet is
optional (MAY, MIGHT etc.) or mandatory (SHOULD, 
MUST etc.)? In such case who is breaking the RFC.

Regards,
Jitesh

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Aug 2003 12:36:00 -0500

> who is not comploying with the RFC? Relay? Or the

If the RFC doesn't say that the relay agent should do this (and it does not) 
then the relay agent shouldn't do it.   This is a completely wrong to thing 
do, because it breaks interoperability by imposing a requirement on the 
server that is not stated in the protocol specification.   I suspect it's a 
bug in some software version that results from some feature they've added, 
rather than something they have decided they ought to do in general.

---

From: "Jitesh N Verma" <[email-masked]>
Date: Mon, 4 Aug 2003 11:45:41 +0530

Hi all,
Ted, thanks a lot for your reply.
I expect some more list members to give their
opinion and then we should build a consensus
on this kind of issues.

Regards,
Jitesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
Lemon
Sent: Saturday, August 02, 2003 11:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Source address and source port problem in DHCP
server

---

From: Sanjeev Verma <[email-masked]>
Date: Mon, 04 Aug 2003 11:05:20 -0700

> rather than something they have decided they ought to do in general.

It is an implementation detail - how to match replies to requests. For 
relay, (xid, mac address, message type)-tuple should be sufficient to 
match replies to requests. But in this case, the relay appears to be 
using (server IP address, port sent out on)-tuple to do either matching 
or additional checking. And that's broken.
   For the sake of completion - under some circumstances, matching 
requests to replies using mac address may also not work. And, if the 
relay is attaching option 82 to relayed requests, that could also effect 
the matching logic in relay.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 04 Aug 2003 14:13:48 -0400

In general, there is no need to match replies to requests.  One of the 
design principles for DHCP is to avoid the requirement for the relay agent 
to maintain any state about individual DHCP messages.  All of the 
information required by a relay agent to forward the reply to the DHCP 
client is contained in the message itself (client MAC and IP 
address).  Even in the case of option 82, the information needed by the 
relay agent to forward the reply to the correct downstream port is 
contained in option 82 itself.

- Ralph

At 11:05 AM 8/4/2003 -0700, Sanjeev Verma wrote:

>>If the RFC doesn't say that the relay agent should do this (and it does 
>>not) then the relay agent shouldn't do it.   This is a completely wrong 
>>to thing do, because it breaks interoperability by imposing a requirement 
>>on the server that is not stated in the protocol specification.   I 
>>suspect it's a bug in some software version that results from some 
>>feature they've added, rather than something they have decided they ought 
>>to do in general.
>
>match replies to requests. But in this case, the relay appears to be using 
>(server IP address, port sent out on)-tuple to do either matching or 
>additional checking. And that's broken.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Aug 2003 13:53:07 -0500

> contained in option 82 itself.

To expand on this a little, of course there are times when it may be desirable 
to make the relay agent do more than a dumb relay agent would, and in those 
cases it may be necessary to match messages, even though the protocol neither 
needs nor suggests such matching.   As Ralph has said, the way to do this is 
with the relay agent information option.   As Ralph has also said, in general 
the relay agent information option should provide enough of a cache for the 
relay that it doesn't actually need to do message matching - it should be 
able to blindly forward the message to the right place based on the 
information returned by the server in the relay agent information option.

At a minimum, any enhancements that are made in the relay agent that are not 
required by the protocol must do no harm.   They must not break 
interoperability.   What the gentleman from HP has described breaks 
interoperability, so any devices that do this are not in compliance with 
RFC951 or RFC2131.   It would be wrong for the manufacturer of these devices 
to claim compliance with either of these protocols if the devices fail to 
deliver relayed messages that are themselves in compliance with the 
protocols.

Of course, as I say, I suspect this is just a bug, so there's probably no need 
for anybody to go around changing any packaging or documentation - they just 
need to fix the bug.   :'}