Subject: Re: [dhcwg] Layer 2 Relay Agent Information draft

From: Ramesh <[email-masked]>
Date: Mon, 4 May 2009 20:01:14 +0530

Pavan,

Pls see inline

-- 
cheers
ramesh

On Tue, Apr 28, 2009 at 10:02 PM, pavan_kurapati <[email-masked]
> wrote:

> Hi Ramesh,
> Sorry for the delay. Please see replies inline
>
> Thanks,
> Pavan
> ________________________________
> From: Ramesh [[email-masked]]
> Sent: Sunday, April 26, 2009 9:50 PM
> To: pavan_kurapati
> Cc: Bharat Joshi; [email-masked]
> 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.

[Ramesh] If so, is it ok to leave an advice to readers about the recommended
implementation?  Otherwise, are we not breaking RFC 3046 ? Please correct me

if I am wrong here.

>
>
> 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.

[Ramesh] Could you please justify this from security perspective? When we
talk about security, I feel, it is ok to lock a genuine client rather than
allowing a malicious client.

> 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

[Ramesh] Ok

>
>
>
> 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.

[Ramesh] If so, will it be good to mention this scenario in which it is
difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state. Otherwise the context is not clear
as the statement is more generic.

>
> --
> cheers
> ramesh
>
>
> On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati <
> [email-masked]<mailto:[email-masked]>> wrote:
> Hi Ramesh,
> Thanks for the review. Please find replies inline
>
> Thannks,
> Pavan
> ________________________________
> From: [email-masked]<mailto:[email-masked]> [
> [email-masked]<mailto:[email-masked]>] On Behalf Of Ramesh
> [[email-masked]<mailto:[email-masked]>]
> Sent: Sunday, April 26, 2009 3:43 PM
> To: Bharat Joshi
> Cc: [email-masked]<mailto:[email-masked]>
> 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 <[email-masked]
> <mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>> 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
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
>
>
>
>
>
>