Re: comments on mipv6 application to multihoming [Re: Move forward]

[Pekka Savola <pekkas@netcore.fi>]

On 16 Mar 2003, marcelo bagnulo wrote:
> > ==> The problem is that this mechanism only "works" (for some definition of
> > works)
> 
> Preserves established sessions perhaps?

Yes -- with certain tradeoffs: to preserve established sessions, you 
*typically* have to react quickly, and of course the sessions should be 
preservable for the duration of the failure, but that's not as hard a 
requirement to me (ie. if you get a warning that connections have failed, 
using backups whic will help you for the next 5 minutes, shut them down 
gracefully if the break is expected to last longer).

 > > >  for sessions that are broken over 140 seconds
> 
> This is an upper bound. I mean it can be reduced but it can not be
> increased. In order to reduce it all that it is needed is to increase
> the frequency of HoTI CoTI message exchange. This would indeed increase
> the overhead, and cost benefit analysis should be performed in order to
> obtain an optimal choice. What it can not be done is to have a longer
> detection period. But if i understand correctly you do not have a
> problem with this.
> 
> Mechanism that provide a faster response to failures have to be included
> once that other problems have been solved (like the next one)

Yes, definitely the reaction time would have to be shorter.  However, I'm 
not sure if the HOTI/COTI exchange is the right mechanism for that: I'm 
not sure whether it scales down properly. (It was never meant as a 
heartbeat mechanism.)
 
> >  (ie. connection is not
> > aborted before that), with the upper bound of 420 seconds. 
> 
> This is the real problem IMO.The alternative address can only be used 
> for a limited period (420 secs). Then you have to
> perform the RR procedure again to obtain new valid authorization data
> that is to be used for extending the lifetime of the new address. THis
> is a major problem since you can not perform the RR procedure because
> the HoA is no longer available. The solution for this would be to extend
> the lifetime of the binding but this may have security implications. you
> have previously worked in MIPv6 security, right? could you comment about
> the security concerns of extending this timer? 

Due to the RR procedure, it doesn't protect you from on-the-link or 
on-the-path attackers.  Attackers which *have been* on the link or on the 
path can wreak havoc to up to MAX_RR_BINDING_LIFETIME (420 s) after 
leaving the link or the path.

Cranking it up significantly would certainly have implications but slight 
modifications probably not so much (e.g. if your friendly router 
implementation rebooting takes 430 seconds, the lifetime could very well 
be 600 seconds).  The order of magnitude matters.

.. but there may be something I'm missing.

> >  On top of that,
> > quite a bit of signalling is performed just in case that a link might go
> > down.
> 
> e2e failure detection implies traffic exchange. It is important to
> discuss whether this overhead is acceptable or not. 

Indeed -- some mechanism do this always, some just after the fact (when 
suspecting some error has occurred, e.g. TCP acks get delayed), some both.

> >  Btw, how does a node know the
> > prefix length of his site?  Not an easy problem, unless it's guessing..
> > 
> 
> Good point!!!
> An option is to consider that it is always a /48, but i don't thik this
> is a good approach.
> Another possibility is to assign the site exit routers anycast address
> of every subnet to the corresponding exit router and propagate it within
> the site as a host route. So hosts will address packets to its own
> subnet exit site router anycast address, which will be routed to the
> correspondent exit router.
> Since the explanation is not so clear i will put an example
> 
> 
> 
>                 +----+                  +----+ 
>                 |R1  |                  |R2  |
>                 |P1::|                  |P2::|
>                 +----+                  +----+ 
> P1:Subnet1:Router1 |    P2:Subnet2:Router2 |
>             -------------------------------------
>             P1:Subnet1:Router3 |
>             P2:Subnet2:Router3 |            
>                             +----+                   
>                             |R3  |                  
>                             +----+                  
>             P1:Subnet3:Router3 |
>             P2:Subnet4:Router3 |
>            -----------------------------------            
>             P1:Subnet3:Host  |
>             P2:Subnet4:Host  |            
>                           +----+                   
>                           |Host|                  
>                           +----+                  
>  So Addresses P1:Subnet1:FFFF:FFFF:FFFF:FFFF and
> P1:Subnet3:FFFF:FFFF:FFFF:FFFF are assigned to R1.
> P1:Subnet3:FFFF:FFFF:FFFF:FFFF is announced within the site as a host
> route to R1
> Addresses P2:Subnet2:FFFF:FFFF:FFFF:FFFF and
> P2:Subnet4:FFFF:FFFF:FFFF:FFFF are assigned to R2.
> P2:Subnet4:FFFF:FFFF:FFFF:FFFF is announced within the site as a host
> route to R2
> So when Host sends a packet whose source address contains the prefix P1,
> it includes a routing header with P1:Subnet3:FFFF:FFFF:FFFF:FFFF which
> is deduced from its own prefix.
> 
> Not very nice, but i guess this would work, don't you?  

Doesn't work -- the host will detect that the prefix is on-link, and will 
try to reach it by sending neighbor solicitation to it.  The access router 
would have to perform proxy-ND for it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings