Re: [dhcwg] Layer 2 Relay Agent Information draft

[pavan_kurapati <[e-mail]>]

Hi Ramesh,
Sorry for the delay. Please see replies inline

Thanks,
Pavan
________________________________
From: Ramesh [[e-mail]]
Sent: Sunday, April 26, 2009 9:50 PM
To: pavan_kurapati
Cc: Bharat Joshi; [e-mail]
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft

Pavan,
Please see comments inline



Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server
_if_ it has inserted option-82. This is because for a client, option-82 do not make any sense.
[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior  given that there are implementations which doesnt do it. I feel 'may' is good here.
[Ramesh] My concern here is, L2RA should intercept all packets from server, as server could do unicast reply for a broadcast request.
As per RFC 3046 information option have to be stripped off by the relay agent which added it,
"

   The Relay Agent Information option echoed by a server MUST be removed
   by either the relay agent or the trusted downstream network element
   which added it when forwarding a server-to-client response back to

   the client.

"
Also, I think it will be harsh on the client by asking it to accept a DHCP option which a client software does not care at all.
Today, there _can_ be DHCP clients which misbehave(?) when it see an option-82, as RFC 3046 clearly removes client's relationship with option-82.
[Pavan] You are right that ideally L2RAs (or any relay agent) which adds Option 82 must be configured to snoop unicast replies to remove the option 82. That is how most of the L2RAs (DSLAMs for eg) work today. However, as I mentioned, there are some L2RAs which cannot snoop unicast messages. Also, please note that this is a informational draft and not a standards draft, so we cannot mandate anything in this draft.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two conflicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn
from the REQUEST+ACK message exchange which involves only one server. So there
is no question of keeping a client state more than its life time. Am I missing
something here?

In any case, Maintaining a state ( and hence filter) even after a client is dead,
mean anomalies.
[Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time.
[Ramesh] I feel we are leaving a security hole here.
Say you have a client which should be leased IP for 10 minutes. One server lease with 10 minutes and another server with 20 minutes of lease interval.
L2RA will assume the client is valid for 20 minutes and tune the filter. Whereas the management box ( eg. BRAS) would think it is valid for 10 minutes.
So it is like allowing an unauthorized client to be active from 10 to 20th time instance. ?
By the way, how is the client expected to behave when it gets two lease. Is it expected to use the address leased by the server corresponding to the server-id?

[Pavan] We feel that all the elements (including BRAS) must take the highest lease time option in this case. Currently, I dont think client has any defined bahavior in this case. BTW, please read the below thread on the origin of this text.
http://www.ietf.org/mail-archive/web/dhcwg/current/msg08427.html


section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an IP and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear.
[Ramesh] My understanding is, if unicast messages are intercepted,
               - RENEW will get option 82 added and giaddr not set.
               - REBIND will get option 82 added and giaddr set.
This difference is sufficient for the DHCP Server to distinguish the client packet.
Did I get something wrong?
[Pavan] There are DHCP servers today which assumes client is in REBIND state if option 82 and client ip address is present. It does not check the 'giaddr' and that was the reason for adding this statement. Let me know if this is still not clear.
--
cheers
ramesh


On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ramesh,
Thanks for the review. Please find replies inline

Thannks,
Pavan
________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] On Behalf Of Ramesh [[e-mail]<mailto:[e-mail]>]
Sent: Sunday, April 26, 2009 3:43 PM
To: Bharat Joshi
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft


Bharat,

Few comments/suggestions. Search for [Ramesh].

Section 4.1.1

-------------
3 ... The DHCP server responds with a DHCPOFFER message after applying its local policies.
[Ramesh] Will it be good to mention ".. after applying its local policies for
address allocation". This is just to make clear of what policy, DHCP is all concerned
about and readers do not relate this to any system policies.



[Pavan] I feel the text is generic and conveys the message.


Section 4.1.1

-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP messages from server
_if_ it has inserted option-82. This is because for a client, option-82 do not make any sense.



[Pavan] Mandating all L2RAs to intercept unicast messages may be too strict behavior  given that there are implementations which doesnt do it. I feel 'may' is good here.

section 4.1.1
-------------
6. ...

DHCPNACK - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok?

[Pavan] Yes, thanks. Will change it.

section 4.2.2

-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of two conflicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn
from the REQUEST+ACK message exchange which involves only one server. So there
is no question of keeping a client state more than its life time. Am I missing
something here?

In any case, Maintaining a state ( and hence filter) even after a client is dead,
mean anomalies.



[Pavan] This condition can occur when multiple DHCP servers are configured for failover. In such a configuration, there are servers which ignore server-id and in certain exceptional conditions may respond to the same IP address request with multiple ACKs. In this scenario, L2RA must take the one which has more lease time.


section 4.3.2

-------------
3 ...Because of this, it could be difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and REBIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out an IP and
hence it would know the state of the client based on T1 & T2.

[Pavan] Actually this state is in terms of client's context. A client would broadcast the dhcp message with client address filled in this state. In case of failover configurations, a REBIND may imply that one of the primary server is not responding [since it is broadcast]. However, in L2RA, since unicast messages are also intercepted and option 82 added, a RENEW may be misunderstood as REBIND by server. Let us know if it is not clear.

--
cheers
ramesh




On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>> wrote:
Hi All,

     We have published version 04 of Layer 2 Relay Agent Information draft. This version addresses several editorial comments provided by Alfred.

     Draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt

Thanks,
Bharat
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
https://www.ietf.org/mailman/listinfo/dhcwg