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

[Pete McCann <mccap@lucent.com>]

Hi, Jayshree,

Jayshree Bharatia writes:
[...]
 > [JB] Proposed text for section 2.
 > From:
 > The Challenge extension, illustrated in figure 1, is inserted in the Agent
 > Advertisements by the Foreign Agent, in order to communicate the latest
 > challenge value that can be used by the mobile node to compute an
 > authentication for its next registration request message.  The challenge is
 > selected by the foreign agent to provide local assurance that the mobile
 > node is not replaying any earlier registration request.  
 > 
 > To:
 > The Challenge extension, illustrated in figure 1, is inserted in the Agent
 > Advertisements by the Foreign Agent, in order to communicate a previously
 > unused challenge value that can be used by the mobile node to compute an
 > authentication for its next registration request message.  The challenge is
 > selected by the foreign agent to provide local assurance that the mobile
 > node is not replaying any earlier registration request.  

Ok, looks good.

 > >  > In addition to this, Henrik proposed a new text for a new 
 > > subsection 2.1. 
 > >  > 
 > >  > 2.1 Handling of Solicited Agent Advertisements
 > >  >
 > >  > When a foreign agent generates an Agent Advertisement in 
 > > response to a  > Router Solicitation [4], some additional 
 > > considerations come into play.  > According to the Mobile IP 
 > > base specification [7], the resulting Agent  > Advertisement 
 > > may be either multicast or unicast.  > 
 > >  > If the solicited Agent Advertisement is multicast, it MUST 
 > > NOT generate a  > new Challenge value and update its window 
 > > of remembered advertised  > Challenges. It must instead 
 > > re-use the most recent of the CHALLENGE_WINDOW  > 
 > > Advertisement Challenge values.  > 
 > >  > If the agent advertisement is unicast back to the 
 > > soliciting mobile node  > MUST be handled as follows: If the 
 > > challenge most recently unicast to the
 > >   ^ insert the word "it"
 > > 
 > >  > soliciting mobile node has not been previously used (as 
 > > defined in Section  > 1.1), in SHOULD  > be repeated in the 
 > > newly issued unicast agent advertisement, otherwise a new  > 
 > > challenge MUST be generated and remembered as the most recent 
 > > challenge  > issued to the mobile node. (For further 
 > > discussion of this, see Section 12.)
 > > 
 > > I agree with this so far.
 > > 
 > >  > A foreign agent SHOULD NOT respond arbitrarily often to 
 > > agent solicitations,  > in order to limit processing load, 
 > > especially in the face of hostile nodes  > soliciting at a 
 > > very high rate. The rate of solicited agent advertisement  > 
 > > responses SHOULD at most be 50 per second.
 > > 
 > > I am not sure we need the last paragraph.  Overload control, 
 > > especially the choice of which solicitations to discard, is a 
 > > tricky subject.  I don't know that we will come to any 
 > > agreement on a maximum rate (cf. previous discussions on the 
 > > Mobile IP list regarding multicast agent advertisement rates).
 > > 
 > > 
 > >  > The original proposal from Henrik was to mandate a 
 > > challenge in a  > Registration Reply. After few email 
 > > exchanges, it was decided that the  > current text in section 
 > > 3.3 (RFC3012bis (version 05) ) is ok. In addition to  > the 
 > > current text, Henrik proposed the following text to be used 
 > > as a  > guidance/background:  > 
 > >  > (section 3.3)
 > >  > One example of a situation where the Foreign Agent MAY 
 > > omit the inclusion of  > a Mobile-Foreign Challenge Extension 
 > > in the Registration Reply would be when  > a new challenge 
 > > has been multicast recently. 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.
 > > 
 > > This is good, but it doesn't seem quite strong enough, i.e., 
 > > we still have a SHOULD on the inclusion of the previously 
 > > unused challenge.  It seems to me we should require (with a 
 > > MUST) the inclusion of a challenge in the registration reply 
 > > if something like the condition above isn't met, and 
 > > similarly should require (with a MUST) the inclusion of a 
 > > challenge in responses to Agent Solicitations if the 
 > > condition isn't met.  This is the only way to guarantee 
 > > progress on a link where advertisements may be lost and where 
 > > there is a long interval between unsolicited advertisements.
 > > 
 > > 
 > [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?

 > By the way, the current text in
 > section 3.3 is: "The Foreign Agent SHOULD include a new Mobile-Foreign
 > Challenge Extension in any Registration Reply, successful or not. "
 > 
 > I like to see use of term "previously unused challenge" instead of "new".

Makes sense.

[...]
 > > I don't support the text changes above, although I may have 
 > > proposed the principle of "repeating challenges."  Perhaps we 
 > > don't need to make any text changes in this section, but can 
 > > confine the new text to the security considerations (see my 
 > > proposal below).
 > > 
 > > 
 > [JB] I don't have any problem removing these changes. The proposed text does
 > what was intended and that is, allowing repetition of challenges when
 > authentication fails. 

Agreed.

[...]
 > > Based on the subsequent discussion, I don't think we need the 
 > > text changes above.  See the security considerations:
 > > 
 > > 
 > [JB]OK
 > 
 > >  > The following text was proposed to be added in section 12. 
 > > This is a  > modified version of the text proposed by Henrik 
 > > on the mailing list earlier.  > 
 > >  > (section 12)
 > >  > 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 
 > > SHOULD repeat the same challenge value  > in successive 
 > > unicast responses to Agent Solicitations or in Registration  
 > > > Replies to Requests that did not contain valid MN-AAA or 
 > > MN-FA  > authentication extensions.  Note that each challenge 
 > > returned to an MN MUST  > be previously unused by that MN.
 > > 
 > > Based on subsequent comments from Ahmad, maybe we can make 
 > > the requirement more generic here, and give a specific 
 > > example in Appendix E.  For here, how about:
 > > 
 > > 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.

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

-Pete


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