RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

[Pete McCann <mccap@lucent.com>]

Hi, Jayshree,

Jayshree Bharatia writes:
[...]
 > >  > [JB] This is the mechanism where the FA provides an unused 
 > > challenge to the  > MN so that the MN can use this challenge 
 > > in the subsequent request. If  > advertisements are lost or 
 > > their interval is long enough, the MN can always  > request a 
 > > challenge by sending Agent Solicitation.
 > > 
 > > But then we need to mandate that a previously unused 
 > > challenge will appear in the solicited Agent Advertisement, 
 > > unless an unsolicited advertisement with a challenge is sent 
 > > immediately before or after. This is the only way to 
 > > guarantee progress.
 > > 
 > > How about this for a specific text proposal:
 > > 
 > >    The FA MUST include a previously unused challenge in each
 > >    Registration Reply or solicited Agent Advertisement, unless an
 > >    unsolicited multicast advertisement containing a previously unused
 > >    challenge is sent immediately before or after (e.g., within 1
 > >    second of) the Reply or solicited Advertisement.  The Foreign Agent
 > >    could then assume that the mobile node with high likelihood has
 > >    received and can use the multicast challenge.  A mobile 
 > > node MUST be
 > >    prepared to use a multicast challenge in lieu of one returned in a
 > >    Registration Reply, and MUST solicit for one if it has not already
 > >    received one in a Registration Reply or Agent Advertisement.
 > > 
 > > [Henrik, I also saw your text proposal on this, but I think 
 > > it may be a bit too wordy.]
 > > 
 > >  > I would think that this
 > >  > type of guideline adds more confusion.
 > > 
 > > What do you think of the text above?
 > [JB] Not sure how much we can rely on the assumption of FA regarding
 > receiving the challenge at the mobile node since there is no guarantee on
 > the timing on when the MN may receive unsolicited multicast advertisement. 

I would be fine if we deleted the one sentence "The Foreign Agent
could then assume..." from the above (it has no normative value
anyway).

[...]
 > >  > > Note that an active attacker may try to prevent successful 
 > >  > > registrations by sending a large number of Agent 
 > >  > > Solicitations or bogus Registration Requests, each of which 
 > >  > > could cause the FA to respond with a fresh challenge, 
 > >  > > invalidating the challenge that the MN is currently trying to 
 > >  > > use.  To prevent such attacks, the FA MUST NOT invalidate 
 > >  > > previously unused challenges when responding to 
 > >  > > unauthenticated Registration Requests or Agent Solicitations. 
 > >  > >  In addition, the FA MUST NOT allocate new storage when 
 > >  > > responding to such messages, because this would also create 
 > >  > > the possibility of denial of service.
 > >  > > 
 > >  > [JB] Can we explicitly write "new challenge" instead of 
 > > "new storage"?
 > > 
 > > Well, it is really the storage allocation that leads to a 
 > > depletion of resources at the FA.  I was trying to allow for 
 > > super-smart implementations that perhaps could figure out 
 > > some way to allocate new challenges without allocating new 
 > > storage (perhaps some sort of embedded cookie mechanism).  I 
 > > thought this was the implementation flexibility that you and 
 > > Ahmad were asking for.
 > > 
 > [JB] I would think that this is specific to how implementation is done. For
 > the purpose of this draft, we can avoid any implementation specific details.

It might be ok to generate new challenges, as long as you don't
invalidate old ones and don't allocate new storage (deplete
resources).  I was trying to state the requirement in as broad a
fashion as possible so as not to restrict implementations
unnecessarily.

 > >  > >  > It was decided that challenges sent in unicast Agent 
 > >  > > Advertisements and sent  > in Registration Reply messages 
 > >  > > should be treated same at the FA. For this,  > the following 
 > >  > > text is proposed by Henrik and Pete:  > 
 > >  > >  > (change 5.1-Section 3.2)
 > >  > >  > From:
 > >  > >  > The Foreign Agent MUST NOT accept any Challenge in the 
 > >  > > Registration Request  > unless it was offered in last 
 > >  > > Registration Reply issued to the Mobile Node,  > or else 
 > >  > > advertised as one of the last CHALLENGE_WINDOW (see section 
 > >  > > 9)  > Challenge values inserted into the immediately 
 > >  > > preceding Agent  > advertisements.  > 
 > >  > >  > To:
 > >  > >  > The Foreign Agent MUST NOT accept any Challenge in the 
 > >  > > Registration Request  > unless it was offered in the last 
 > >  > > Registration Reply or unicast Agent  > Advertisement sent to 
 > >  > > the Mobile Node, or else advertised as one of the last  > 
 > >  > > CHALLENGE_WINDOW (see section 9) Challenge values inserted 
 > >  > > into the  > immediately preceding Agent advertisements.  > 
 > >  > >  > (change 5.2-Appendix E)
 > >  > >  > From:
 > >  > >  > In the program fragment, it is presumed that the foreign 
 > >  > > agent keeps an  > array of advertised Challenges 
 > >  > > ("VALID_ADV_CHALLENGES"), a record of the  > last advertised 
 > >  > > challenge used by a mobile node, and  > also a record of the 
 > >  > > last challenge provided to a mobile node in a  > Registration 
 > >  > > Reply.  > 
 > >  > >  > To:
 > >  > >  > In the program fragment, it is presumed that the foreign 
 > >  > > agent keeps an  > array of advertised Challenges 
 > >  > > ("VALID_ADV_CHALLENGES"), a record of the  > last advertised 
 > >  > > challenge used by a mobile node, and also a record of the  > 
 > >  > > last challenge provided to a mobile node in a Registration 
 > >  > > Reply or unicast  > Agent Advertisement.
 > >  > > 
 > >  > > After that, we could add, "To meet the security obligations 
 > >  > > outlined in Section 12, the FA SHOULD use one of the already 
 > >  > > stored, previously unused challenges when responding to an 
 > >  > > unauthenticated Registration Request or Agent 
 > > Solicitation."  > > 
 > >  > [JB] I would think that "already stored" is redundant here.
 > > 
 > > I think it is important to emphasize that the FA is not 
 > > allocating additional storage.
 > [JB] My point is, if the challenge is "previously unused challenge", it is
 > implicit that the storage is already existed.

Not necessarily - one possible interpretation of your suggested text
is for a new "previously unused" challenge to be created.

 > Anyway, this is implementation specific also.

Yes, as is all of Appendix E, which is an example of what kind of data
structures/pseudocode might be used.  Handing out an "already stored,
previously unused" challenge is a way to meet the security
requirements.  If we change the text to say only "previously unused"
then we open the door to the creation of new challenges, with the
possibility of invalidating old ones given the data structure and
pseudocode in Appendix E.  For that reason, it is important to say
explicitly that the "previously used" challenge is also "already
stored."

-Pete


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