Re: [Mip4] Current state of 3012bis solicited agent advertisement issue.

[Henrik Levkowetz <henrik@levkowetz.com>]

Hi Charles,

Tuesday 19 August 2003, Charles wrote:
> 
> Hello Henrik,
> 
> Henrik Levkowetz wrote:
> 
> > > > In this situation, these two implementations, which both follow the
> > > > current RFC 3012, deadlock and never can reach a successful
> > > > registration.
> > >
> > > The client should NOT deadlock.  It should be able to
> > > use the next advertised (unsolicited) challenge.
> > 
> > Seems reasonable (although not explicitly described in 3012).
> 
> Is it needed to specify that a client MUST be able to receive
> a multicast solicitation even though it has received a Registration
> Reply message...?

 ,:-] Apparently it might be needed to specify something like that...

> 
> >                                           Obviously, we want sane
> > implementations of both unicast solicited advertisements and multicast
> > solicited advertisements (if we want to keep both kinds), so the goal of
> > the text clarifications which has been proposed and discussed is just
> > that.
> 
> I'm happy with clarifications, but I'd prefer not to create
> additional restrictions except where they're needed.  Aren't both
> kinds of advertisements useful?  In fact, originally there was
> only the multicast variety, but the unicast registration extensions
> seemed pretty handy...

Yes, I think both are useful. We just have to make sure that we don't
get bad implementations out there. The original impetus for my postings
on this subject was to get solicited advertisements specified, for
this reason. 

> > One of the more disadvantageous implementations would be one where a
> > solicitation resulted in the generation of a new (multicast) challenge,
> > which would take the most recent slot of the CHALLENGE_WINDOW remembered
> > challenges. The lifetime of any challenge could then be severely reduced
> > by a malicious node soliciting with a high frequency.
> 
> That would be bad.  In fact, I think it would be reasonable to
> specify an upper limit on the frequency of multicast advertisements,
> not more than a few each second.

I could go with that - although I guess my idea of a few might be as many
as 50 or so, as a rough guess.

> > Another disadvantageous implementation would be to respond with unicast
> > solicited advertisements with a fresh challenge, treated in the same
> > manner as challenges returned to individual nodes in registration
> > replies. As there is only one valid such challenge remembered for each
> > individual node, a rogue node would then at any time be able to solicit
> > for a new advertisement, which would make any challenge individually
> > provided to the proper node earlier forgotten, i.e. invalid.
> 
> This should be allowed, certainly, but not mandated.   The problem is
> that we have to avoid making the foreign agent work "too hard" when
> generating good random numbers.  It's not trivial in terms of processing
> requirement.

Ok on the processing requirements. Our proposal for handling this situation
(as manifested in the text proposals) is simply to not calculate new individual
challenges as long as there is an unused challenge available for the node.
In that situation we would rather repeat that challenge.

> >>> Here are proposed text changes for 3012bis, to ensure this deadlock
> >>> does not occur          ...........
> >
> >> But what if there isn't a deadlock situation?
> > 
> > Well, we observed one...
> 
> Was it different than the situation described above?  But then
> I thought you agreed that the deadlock shouldn't occur...(?)

Shouldn't, but did. It was as described in the summary, and prompted,
rather than completely encompassed, the solicited advertisement issues
discussed later.  

	Regards,
		Henrik






_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4