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

[Henrik Levkowetz <henrik@levkowetz.com>]

Pete, Jayshree,

	Commenting on some specific proposals from Pete below (chair hat off):

Friday 29 August 2003, Pete wrote:
> 
> Hi, Jayshree,
> 
> I am reorganizing all the text proposals into this one note for easier
> reference.  See comments below, and let me know if I missed one of
> your notes.
> 
> 
> [note chair hat is off for the remainder of this message]
> 
> 
>  > The current proposal for issue 1 is to use "previously unused challenge" in
>  > section 2 for all multicast and unicast Agent Advertisements. 
> 
> I am not sure what you mean by this.  Can you give a specific text
> proposal, and a location for it in the draft?
> 
>  > 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).

I'm ok with not specifying any particular maximum rate. What adding some
text to the security considerations section about this (in addition to
the proposal you (Pete) make further down) :

    "In order to limit processing load, a foreign agent need not respond 
    arbitrarily often to agent solicitations. In the face of hostile nodes
    soliciting at a very high rate, a foreign agent MAY limit the rate of
    agent advertisement responses."


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

Ok. What about the following text, instead of the proposed paragraph above:

  "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. 
  
  If a foreign agent has conditions in which it omits the inclusion of a
  Mobile-Foreign Challenge Extension in the Registration Reply, it still
  MUST respond with an agent advertisement containing a previously unused
  challenge in response to a subsequent agent solicitation from the same
  mobile node.  Otherwise (when the said conditions are not met) the
  foreign agent MUST include a previously unused challenge in any
  Registration Reply, successful or not.
  
  A mobile node MUST be prepared to use a challenge from a unicast or
  multicast Agent Advertisement 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."

> 
> 
> 
>  > The current proposal from Pete is to reuse the challenge in the Registration
>  > Reply of the Registration Request for which the authentication fails at the
>  > FA. This challenge sent in the Registration reply will be same as the
>  > challenge received in the Registration Request for which the reply is sent.
>  > 
>  > To reflect this point, the following changes are proposed by Jayshree:
>  > 
>  > (change 2.1-Section 3.2)
>  > From:
>  > If the registration message contains a Mobile-Foreign Authentication
>  > extension with an incorrect authenticator that fails verification, the
>  > Foreign Agent MAY send a Registration Reply to the mobile node with Code
>  > value BAD_AUTHENTICATION (see Section 10). 
>  > 
>  > To: (Added last statement) 
>  > If the registration message contains a Mobile-Foreign Authentication
>  > extension with an incorrect authenticator that fails verification, the
>  > Foreign Agent MAY send a Registration Reply to the mobile node with Code
>  > value BAD_AUTHENTICATION (see Section 10). In this case, if  the Mobile Node
>  > is currently registered, the challenge included in the  Registration Reply
>  > by the Foreign Agent MUST be the same as the one received in the
>  > Registration Request.
>  >
>  >
>  > (change 2.2-Section 3.2)
>  > From:
>  > If the registration message contains a Mobile-AAA Authentication extension
>  > with an incorrect authenticator that fails verification, the Foreign Agent
>  > MAY send a Registration Reply to the mobile node with Code value
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA. 
>  > 
>  > To: (Added last statement)
>  > If the registration message contains a Mobile-AAA Authentication extension
>  > with an incorrect authenticator that fails verification, the Foreign Agent
>  > MAY send a Registration Reply to the mobile node with Code value
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if  the Mobile Node is
>  > currently registered, the challenge included in the Registration Reply by
>  > the Foreign Agent MUST be the same as the one received in the Registration
>  > Request.
>  > 
>  > (change 2.3-Section 3.5)
>  > From:
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if
>  > the Registration Request contains a Mobile-AAA Authentication extension with
>  > an incorrect authenticator that fails verification.  A Mobile Node that
>  > receives a
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new Challenge value in any new
>  > registration, obtained either from an Agent Advertisement, or from a
>  > Challenge extension to the Registration Reply containing the error.
>  > 
>  > To: (Replaced "new Challenge" to "Challenge")
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if
>  > the Registration Request contains a Mobile-AAA Authentication extension with
>  > an incorrect authenticator that fails verification.  A Mobile Node that
>  > receives a
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a Challenge value in any new
>  > registration, obtained either from an Agent Advertisement, or from a
>  > Challenge extension to the Registration Reply containing the error.
> 
> 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).

Ok with me.

>  > This change further extends point mentioned in change 1 for issue 2. The
>  > proposal from Henrik was to clarify the use of challenge. This text is
>  > intended as a new paragraph in section 3.3. 
>  > 
>  > "If the challenge most recently issued to the soliciting mobile node has not
>  > been previously used (as defined in Section 1.1), the most recent challenge
>  > unicast to the mobile node through a registration reply or a unicast agent
>  > advertisement SHOULD be repeated in the registration reply."
>  > 
>  > This proposal was further modified by Pete differentiating the processing at
>  > the FA for the registered and unregistered users:
>  > 
>  > "When responding to an unregistered MN with an unsuccessful Registration
>  > Reply, the FA SHOULD include the same challenge that was last included in a
>  > multicast Agent Advertisement.  When responding to a registered MN with a
>  > successful or unsuccessful Registration Reply, the FA SHOULD include the
>  > same challenge that was last included in a multicast Agent Advertisement,
>  > when that challenge is previously unused by the MN.  Otherwise, the FA
>  > SHOULD include the same challenge that was previously unicast to the MN in a
>  > Registration Reply or Agent Advertisement, unless that challenge was
>  > previously used.  In that case, the FA SHOULD create a new challenge and
>  > return it to the MN, storing a copy of it with the visitor list entry for
>  > that MN."
> 
> Based on the subsequent discussion, I don't think we need the text
> changes above.  See the security considerations:

I'm ok with skipping this change and handling it through the security
consideration change proposed.

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

Ok with me.

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

Ok with me.

	Regards,
		Henrik

Attachment: pgp00006.pgp
Description: PGP signature