[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on mipv6 application to multihoming [Re: Move forward]
On Tue, 2003-03-18 at 01:58, Pekka Savola wrote:
> 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).
>
I like this approach. However, i would really prefer that connections
could survive 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.)
>
I was, however designed to prevent DoS attacks, imposing minimal
workload to CN. No state nor crypto is needed to generate HoT or CoT
messages. I would say it is ok...
> > > (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.
>
Again, i think that the solution would be much more valuable if
connections could survive much longer. I have a proposal to extend
MAX_RR_BINDING_LIFETIME, but it is a bit long to include it in here. If
you would like to consider it, i can send it to you. (i would appreciate
it very much)
> > > 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.
Good point (again)
I am running out of solutions here :-)
I can think of the following options for this, but i am not sure i like
anyone of them.
First option: (i think this would be the most elegant, but i think its
time has passed) use a site local anycast address
So you can compose the site exit router anycast address by appending the
prefix assigned to the link to the site local prefix. I like this, but
the problem is that there may be no more site locals for connected
sites. I guess i should wait and see the outcome of the site local
debate.
Second option: use the above configuration and configure R3 as a ND
proxy. I do not like this much because it imposes additional
configuration in all the routers (it is better than configuring all the
hosts, though)
Third option: (nasty hack) use the above configuration but change the
site exit router anycast format by changing the less significant bit of
the directly attached subnet. This would make that the anycast address
is not on-link, so that it has to be routed through a router.
Opinions?
Regards, marcelo
--
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m