[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [savi] Broadband Forum liaison to IETF on IPv6 security



HI Alberto:

The unfortunate answer to all of your question is "it depends..."

I believe it would be safe to suggest that one BNG would enforce uniqueness, although architectures could be considered where a second BNG was effectively a warm standby for a given broadcast domain... One BNG will be the repository for all active customer facing "state" any any given time...

We do have scenarios where a service provider test set may move around the network, but the common case is the RG association with a single port is very long lived....

W.r.t. NUD, we have had discussions of the role of NUD vs. our use of BFD or other protocols for IPv4, but others will have to comment on the current state of play....

My second answer above would tend to complicate any form of sticky binding...although a coupling to a PHY outage as a binding invalidation would likely address that scenario, but that would require messaging that is not necessarily deployed today (ANCP notwithstanding)...

Hope that helps
D

-----Original Message-----
From: Alberto García [mailto:alberto at it.uc3m.es] 
Sent: Tuesday, November 10, 2009 10:41 AM
To: Christian Vogt; 'SAVI Mailing List'
Cc: David Allan I
Subject: RE: [savi] Broadband Forum liaison to IETF on IPv6 security

Hi,
After looking at the presentation, I have some questions:
- Is address uniqueness enforced in just one BNG? Or an address must be unique also across many BNGs?
- Is mobility assumed to occur among channels (i.e. is reasonable to have Residential Gateways (RG) which are in one channel to move other channel)?
- What is the RG address used for? (frequent use)? At least, does NUD exchange occurs between the RG and the BNG?

Current SAVI proposal for SLAAC is complex because it deals with uniqueness across multiple SAVI devices, and considers that hosts may move to different SAVI devices.

My bet is that this is not the case for Broadband Forum problem. 
Therefore, I assume that it is enough to enforce address uniqueness on each BNG. The first host using an address as source address forces the creation of the binding between the address and this channel. Receiving packets with this source address from the RG extends the life of the binding. Since there is no RG mobility, the binding can be kept until the timer associated to the binding expires (there is no need to be too fast to change, or to probe aggressively if the RG of the first binding is still there). This time can be very long (of course, higher that the time to expire NUD state). 
The BNG should perform proxy ND, i.e. answer to DAD NSOL with DAD NADV if a binding exists and a new RG tries to configure a new address. 
Data packets coming from channels for which there is no binding (the binding is associated to other channel) are discarded.

Does this make sense?

Regards,
Alberto


|  -----Mensaje original-----
|  De: savi-bounces at ietf.org [mailto:savi-bounces at ietf.org] En nombre de  
| Christian Vogt  Enviado el: lunes, 09 de noviembre de 2009 9:41
|  Para: SAVI Mailing List
|  CC: David Allan I
|  Asunto: Re: [savi] Broadband Forum liaison to IETF on IPv6 security
|  
|  Folks -
|  
|  Thank you all for a productive working group meeting this morning!
|  
|  As mentioned during our the meeting, the presentation of David Allan 
| is  the problem statement that was missing in the liaison we had 
| earlier  received from the Broadband Forum.  You find David's slides 
| on the  meeting materials web page:
|  
|  http://www.ietf.org/proceedings/09nov/slides/savi-8.pdf
|  
|  The meeting materials web page now also includes last-minute updates 
| to  the presentation slides you saw during our meeting this morning.
|  Meeting minutes will follow shortly.
|  
|  - Christian
|  
|  
|  _______________________________________________
|  savi mailing list
|  savi at ietf.org
|  https://www.ietf.org/mailman/listinfo/savi


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.