Subject: [savi] FW: savi-dhcp-02 draft

From: "Guang Yao" <[email-masked]>
Date: Wed, 17 Mar 2010 20:00:44 +0800

Hi Eric,

Please see replies inline.

> -----Original Message-----
> From: Eric Levy-Abegnoli [mailto:[email-masked]]
> Sent: Tuesday, March 16, 2010 11:18 PM
> To: Guang Yao
> Cc: 'SAVI Mailing List'
> Subject: Re: [savi] savi-dhcp-02 draft
> 
> Hi Guang,
> I have a questions regarding both the current draft and this discussion.
> 
> 1) When you learn a binding by snooping DHCP REQUEST/REPLY, you read the
> client IP address out of the IADDR option, right?
> Where do you get the MAC address from in case it is the anchor? Is it
> the SMAC of the request? The DMAC of the server response? Or is it the
> DUID in the clientID option?
[Guang Yao] 
Because anchor should be learn from request message(or with request
message), and DUID may not contain the link layer address, I prefer SMAC in
the request.

> 
> 2)When a switch is trying to retrieve bindings that it _never_ knew, per
> the topo changes discussion, it goes to the server with a LEASEQUERY.
> Get back an Address and a ClientID (carrying a DUID). No port, right? So
> in case the anchor is the port, where is it learning the port from in
> this scenario?
[Guang Yao] 
This procedure is triggered by data packet received from a port, and then
the port can be learned with the data packet.

I know it may be not quite secure. Malicious node can send packet with
address of another node. Because leasequery just ensures the address is
assigned, the savi will bind the address with the malicious node. Thus this
function (savi-datatrigger attribute), must only be configured on selected
port in very specified scenario( as described by Marcelo).
> 
> 3) The DUID carried in the ClientID is _not_ always the SMAC that the
> client will use to source packets for the IP address requested. If you
> disagree with that, I can develop ... So whether in 1) or 2) this cannot
> be used. For 1) we can always use the SMAC of the request (of DMAC of
> the response). For 2), what else do we have?
> 
[Guang Yao] 
Maybe the above explanations are not clear. Data triggered lease query is
not used to bind anchor and SIP with absolute security(and impossible), but
just to avoid packet loss in very specified scenarios. The binding is loose
but not dangerous to other node.

And this is not a MUST function. It can be turned off to achieve strict
security.

> Thanks for clarifying all these points.
> Eric
> 
> Guang Yao a écrit :
> > Hi Eric,
> >
> > The method that save bindings in non volatile memory is described in
section
> > 21. Thanks for your previous suggestion.
> >
> > The data triggered dhcp lease query is not used to restore previous
> > bindings, but to set up bindings the device _never_ gets known. The
> > scenarios include movement on local link, and layer 2 topo changes, as
> > discussed recently.
> >
> > BR,
> > Guang
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >>
> > Eric
> >
> >> Levy-Abegnoli
> >> Sent: Monday, March 15, 2010 10:13 PM
> >> To: Guang Yao
> >> Cc: 'SAVI Mailing List'
> >> Subject: Re: [savi] savi-dhcp-02 draft
> >>
> >> Hi Guang,
> >>
> >> Guang Yao a écrit :
> >>
> >>> Hi Eric,
> >>>
> >>> Thanks for your suggestion. Your experience is very valuable.
> >>>
> >>> In this solution, sending DHCP lease query is optional, just to handle
> >>>
> > some
> >
> >>> special cases (in general, data triggered but rather control packet).
It
> >>>
> > is
> >
> >>> not required to be enabled. Vendors may choose to implement it on
layer
> >>>
> > 3
> >
> >>> device but not pure layer 2 device. And network administrators may not
> >>> enable this function if they find the device may be overloaded.
> >>>
> >>> If binding is learnt from NDP, IMO it should be bound in savi-slaac,
but
> >>>
> > not
> >
> >>> in this solution for DHCP. And the which to prefer in case of
> >>>
> > co-existing of
> >
> >>> NDP and DHCP, I think should be specified in the framework doc. Am I
> >>>
> > right?
> >
> >>> BR,
> >>> Guang
> >>>
> >>>
> >> What I meant is that the proposed method (sending a leasequery to
> >> re-discover a binding lost in case of the switch reboot) cannot be used
> >> as a "general" response to the problem raised. A switch, L2-only
device,
> >> that looses its binding table and has no non-volatile memory has just
no
> >> way to recover it thru DHCP. It's is unfortunate since DHCP is
> >> considered as the only authoritative method for discovering bindings.
> >> I would consider that at the stage, when DHCP is used, non-volatile
> >> memory is the only option.
> >> Eric
> >>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> >>>>
> >>>>
> >>> Eric
> >>>
> >>>
> >>>> Levy-Abegnoli
> >>>> Sent: Monday, March 15, 2010 8:58 PM
> >>>> To: Bi Jun
> >>>> Cc: SAVI Mailing List
> >>>> Subject: Re: [savi] savi-dhcp-02 draft
> >>>>
> >>>> Bi Jun a écrit :
> >>>>
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> This is a revised version of savi-dhcp (revised based on the
> >>>>> discussion of dhcp-01 on the mailing-list in the past week),
> >>>>> basically, make the control packet-triggered functions as MUST (low
> >>>>> cost to be implemented in every switch), and have the data-triggered
> >>>>> functions (more complex to be implemented) as optional for
higher-end
> >>>>> switches (to enable more flexible use of savi device).
> >>>>>
> >>>>> We are consulting the vendors on the cost for those options.
> >>>>>
> >>>>> please give us your comments.
> >>>>>
> >>>>> thanks,
> >>>>> Jun Bi SAVI
> >>>>>
> >>>>>
> >>>> J.
> >>>>
> >>>>
> >>>>> Bi, J. Wu
> >>>>>
> >>>>>
> >>>> Hi Jun bi,
> >>>> Reading the below:
> >>>>
> >>>>       "IPv6 address:
> >>>>       Send a LEASEQUERY [RFC5007] message querying by IP address
> to
> >>>>       All_DHCP_Relay_Agents_and_Servers multicast address or a
> >>>>       configured server address. If no successful LEASEQUERY-REPLY is
> >>>>       received, discard the packet; otherwise generate a new binding
> >>>>       entry for the address. The SAVI device may repeat this process
if
> >>>>       a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in
> >>>>
> >> order
> >>
> >>>>       to set up binding entries for all the address of the client."
> >>>>
> >>>> I don't think the below proposal to discover IPv6 address from the
savi
> >>>> device works.  DHCP messages must be sourced with an IPv6 address
> >>>>
> >> (can't
> >>
> >>>> be UNSPEC, must be a link-local) and in most cases, the switch does
not
> >>>> have any.  That would take the switch to have a L3 interface that
> >>>> participate in the link operations (for each of its vlans), and that
is
> >>>> a huge constrain.
> >>>> I have real deployment examples of pure L2 switch devices with
> >>>>
> > thousands
> >
> >>>> of vlans configured (hundreds of ports in each vlan). Getting a L3
> >>>> address in each vlan would have a huge impact on the switch
operations
> >>>> and performances.That does not seem acceptable.
> >>>> I think the only option is to discover the binding by probing with a
> >>>>
> > NDP
> >
> >>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable for a
> >>>>
> > L2
> >
> >>>> device.  Then install the binding as learnt from NDP. And later,
> >>>> "prefer" the DHCP binding when/if it shows up.
> >>>> Eric
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> savi mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/savi
> >>>>
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> savi mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/savi
> >>
> >
> > _______________________________________________
> > savi mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/savi
> >
> >