Re: [dhcwg] Layer 2 Relay Agent Information draft

[Ramesh <[e-mail]>]

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.

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?



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?

-- 
cheers
ramesh


On Sun, Apr 26, 2009 at 7:04 PM, pavan_kurapati
<[e-mail]>wrote:

> Hi Ramesh,
> Thanks for the review. Please find replies inline
>
> Thannks,
> Pavan
> ________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Ramesh
> [[e-mail]]
> Sent: Sunday, April 26, 2009 3:43 PM
> To: Bharat Joshi
> Cc: [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]>> 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]>
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
>
>