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

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



Hi

|  -----Mensaje original-----
|  De: David Allan I [mailto:david.i.allan at ericsson.com]
|  Enviado el: miércoles, 11 de noviembre de 2009 1:42
|  Para: Alberto García; Christian Vogt; 'SAVI Mailing List'
|  Asunto: 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...

Well, the problem would be to enforce uniqueness across several BNGs
operating in parallel.
The event of having a backup BNG assuming the role of a failed BNG could be
handled in a specific way, or just not handled at all. In this last case, if
a new BNG replaces an old one, even if it does not have the state of the
first BNG, it will learn it from the data packets it is receiving. Every RG
would be unprotected (in the sense that a different RG could obtain the
address of another RG that was operating successfully with that address) for
some time (until each RG sends its first packet). ICMPs should be used to
inform the RGs. But it would never occur that two addresses were in use at
the same time. Would this be a problem?

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

Maybe manual special bindings could be set for the addresses of these test
devices (e.g. a binding to ANY port, instead of to one particular port,
meaning that an RG in any port could use this address). 
Or make the test devices changing its address each time the move.
Or make the test devices using SEND to validate securely, and make BNGs to
check the signature of a DAD NSOL to change the binding immediately for the
new port through which DAD NSOL is received.

It depends on if you don't care very much to configure the BNG/the test
devices

Is this reasonable?

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

The real requirement would be to have packets sent from the RG (containing
its source address) periodically, to be able to create/refresh the binding.
They can either result from NUD exchange, BFD, whatever, while they contain
the IPv6 source address of the RG.

Regards,
Alberto

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