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

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Aug 2003 10:35:06 +0200

This is a summary of the status of the issue of how to handle
solicited agent advertisements with challenges according to 3012bis.

There has been few participants so far in these discussions. In
order to gauge consensus, please respond to the individual proposed
text poits below if you have a position, and indicate whether you
support or oppose the text as proposed.  

This includes those who have already participated in the discussions,
too, as it has not always been easy to determine exactly where there is
and is not consensus when going over the notes:

---

Background:

The current RFC3012 text says that an FA MAY include a new challenge in
any registration reply, successful or not. 

At least one current implementation accordingly does not return a
challenge with the registration reply when the registration attempt for
some reason is unsuccessful (could be a timestamp mismatch with the HA,
or some other rectifiable issue with the first registration request).

At least one other current implementation expect an unsuccessful
registration reply to provide a new challenge (as the challenge used in
the previous registration request cannot be used again, and may have
been taken from the most recent unsolicited agent advertisement).

In this situation, these two implementations, which both follow the
current RFC 3012, deadlock and never can reach a successful
registration.

The implementation which does not supply a new challenge with an
unsuccessful registration reply expects an advertisement solicitation,
and will provide a fresh challenge in this case, but whether a fresh
challenge or a repeat of the most recent unsolicited multicast
challenge should be provided in a solicited advertisement is also not
specified in the current document text. 

The discussions around this subject also brought to light a number
of denial of service attacks which would be possible with certain
ways of resolving the issues above.

---

Here are proposed text changes for 3012bis, to ensure this deadlock
does not occur, and to prevent more grave denial of service attacks
than could occur in a non-3012bis situation. The text has been taken
from explicit text proposals and from the discussion notes when no
explicit text has been provided earlier.

Proposed text:

- Add at the end of section 2 (as Section 2.1) - or as section 3.6

  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.
    However, a foreign agent which provides challenge handling according
    to this document is restricted to only respond with unicast agent
    advertisements in response to a router solicitation.

    The agent advertisement which is unicast back to the soliciting
    mobile node MUST be handled as follows: A new Challenge value MUST
    be re-generated periodically and remembered as the most recent
    challenge issued to the mobile node. It is RECOMMENDED that this
    period be on the order of 60 seconds. If the challenge most recently
    issued to the soliciting mobile node has not been previously used
    (as defined in Section 1.1), and the re-generation period has not
    elapsed, the most recent challenge unicast to the mobile node
    through a registration reply or a unicast agent advertisement SHOULD
    be repeated in the newly issued unicast agent advertisement. (For
    further discussion of this, see Section 12.)

- In section 3.2, change

  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.  

- In section 3.3, change

  From:
     The Foreign Agent SHOULD include a new Mobile-Foreign Challenge
     Extension in any Registration Reply, successful or not.  If the
     foreign agent includes this extension in a successful Registration
     Reply, the extension SHOULD precede a Mobile-Foreign authentication
     extension. Suppose the ...

  To:
     A Foreign Agent which provides challenge handling according to this
     document MUST include a previously unused Mobile-Foreign Challenge
     Extension in any Registration Reply, successful or not.  If the
     foreign agent includes this extension in a successful Registration
     Reply, the extension SHOULD precede a Mobile-Foreign authentication
     extension. 

     If the challenge most recently issued to the soliciting mobile node
     has not been previously used (as defined in Section 1.1), and the
     re-generation period (as described in section 2.1) has not elapsed,
     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.

     Suppose the ...

- Add the following at the end of 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 for some limited period of time (on the order of 60
    seconds).  Note that each challenge returned to an MN MUST be
    previously unused by that MN.

- In Appendix E, change the second paragraph

  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.

---

As mentioned above, if you have a position on this issue, please respond
to the list, indicating your acceptance or rejection of each individual 
text proposal.

	The chairs.

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: "Espen Klovning" <[email-masked]>
Date: Mon, 18 Aug 2003 10:17:32 +0200

Henrik

We are happy with the proposed text. It will solve some of the interop
issues we have seen.

espen
Espen Klovning
Birdstep Technology ASA

-> Proposed text:
->
-> - Add at the end of section 2 (as Section 2.1) - or as section 3.6
->
->   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.
->     However, a foreign agent which provides challenge handling according
->     to this document is restricted to only respond with unicast agent
->     advertisements in response to a router solicitation.
->
->     The agent advertisement which is unicast back to the soliciting
->     mobile node MUST be handled as follows: A new Challenge value MUST
->     be re-generated periodically and remembered as the most recent
->     challenge issued to the mobile node. It is RECOMMENDED that this
->     period be on the order of 60 seconds. If the challenge most recently
->     issued to the soliciting mobile node has not been previously used
->     (as defined in Section 1.1), and the re-generation period has not
->     elapsed, the most recent challenge unicast to the mobile node
->     through a registration reply or a unicast agent advertisement SHOULD
->     be repeated in the newly issued unicast agent advertisement. (For
->     further discussion of this, see Section 12.)
OK

-> - In section 3.2, change
->
->   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.
OK

->
-> - In section 3.3, change
->
->   From:
->      The Foreign Agent SHOULD include a new Mobile-Foreign Challenge
->      Extension in any Registration Reply, successful or not.  If the
->      foreign agent includes this extension in a successful Registration
->      Reply, the extension SHOULD precede a Mobile-Foreign authentication
->      extension. Suppose the ...
->
->   To:
->      A Foreign Agent which provides challenge handling according to this
->      document MUST include a previously unused Mobile-Foreign Challenge
->      Extension in any Registration Reply, successful or not.  If the
->      foreign agent includes this extension in a successful Registration
->      Reply, the extension SHOULD precede a Mobile-Foreign authentication
->      extension.
->
->      If the challenge most recently issued to the soliciting mobile node
->      has not been previously used (as defined in Section 1.1), and the
->      re-generation period (as described in section 2.1) has not elapsed,
->      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.
->
->      Suppose the ...
OK

->
-> - Add the following at the end of 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 for some limited period of time (on the order of 60
->     seconds).  Note that each challenge returned to an MN MUST be
->     previously unused by that MN.
OK

->
-> - In Appendix E, change the second paragraph
->
->   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.
OK

---

From: Kent Leung <[email-masked]>
Date: Tue, 19 Aug 2003 13:35:54 -0700

All points look good to me.

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 Aug 2003 15:14:17 -0700

> current RFC 3012, deadlock and never can reach a successful

The client should NOT deadlock.  It should be able to
use the next advertised (unsolicited) challenge.

> specified in the current document text.

Either one should work, presumably...(?)

> ways of resolving the issues above.

I saw the one about how a client could "use" the unsolicited
advertisements, BUT the foreign agent should not be fooled.
In fact, a challenge used by one mobile node should still be
able to be used by another mobile node (with a different IP
address).  So, this does not seem like a very potent threat.

> explicit text has been provided earlier.

But what if there isn't a deadlock situation?

> Proposed text:

I'll look at this next!

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 Aug 2003 15:35:57 -0700

Hello again folks,

>     advertisements in response to a router solicitation.

This seems O.K.
 
>     further discussion of this, see Section 12.)

I don't understand the need for the periodic regeneration.   Perhaps
this is because I didn't follow all the previous discussion, but
it seems to me that the mobile can retransmit its solicitation if
it didn't get a challenge, and I can't think of any other reason for
the periodic advertisement to be unicasted.

>      Challenge values inserted into the immediately preceding Agent

Looks O.K.

>      Reply, the extension SHOULD precede a Mobile-Foreign authentication

I don't understand why this is.  It would be especially unneeded if,
for instance, the foreign agent had just sent a multicast Challenge value
a few milliseconds earlier.

>      repeated in the registration reply.

Here, again, I fail to see the point of the regeneration period.
I hope someone won't mind educating me about it.

>     previously unused by that MN.

Even better if the foreign agent allows more than one mobile node
to use the same challenge value.  Why not?

>     Registration Reply or unicast Agent Advertisement.

This seems O.K.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 Aug 2003 16:15:36 -0700

Hello Henrik,

Henrik Levkowetz wrote:

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

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

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

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

>>> does not occur          ...........
>
> Well, we observed one...

Was it different than the situation described above?  But then
I thought you agreed that the deadlock shouldn't occur...(?)

Regards,
Charlie P.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 20 Aug 2003 00:49:39 +0200

> Either one should work, presumably...(?)

Either one would work for the client, but there are different pros
and cons, with some of the cons being rather disadvantageous, as
discussed earlier.

> address).  So, this does not seem like a very potent threat.

This is true for certain possible implementations of solicited
advertisements, but not for others. 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.

Well, we observed one...

> I'll look at this next!

Right-o.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 20 Aug 2003 01:08:40 +0200

Hi Charles,

	Responding to the particular points where you had further comments:

> Hello again folks,

[...]

> the periodic advertisement to be unicasted.

Some other people also had objections to the periodic regeneration.
It would only be necessary if the FA and mobile node had conflicting
ideas about the validity of a challenge, and even then there would be
the option of waiting for the next multicast advertisement. My impression
is that we should skip the regeneration.

[...]

> a few milliseconds earlier.

Yes. But then we will have to specify under which circumstances one
could omit returning a new challenge in a registration reply. The
current text has resulted in at least one implementation which never
return a new challenge with an unsuccessful registration reply, which
was one component in the observed deadlock.

> I hope someone won't mind educating me about it.

As indicated above, we don't really need it and it seems we don't have
consensus on it.

> to use the same challenge value.  Why not?

This is the case with multicast challenges, of course. But currently we
only require the FA to remember one individual challenge per mobile
node, and if an impostor has the ability to invalidate that one (by
causing it to be replaced by a newer one) it has blocked the mobile from
succeeding in its next registration attempt.

	Regards,
		Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 20 Aug 2003 01:45:22 +0200

Hi Charles,

> a multicast solicitation even though it has received a Registration

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

> only the multicast variety, but the unicast registration extensions

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. 

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

> generating good random numbers.  It's not trivial in terms of processing

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.

> 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

---

From: Pete McCann <[email-masked]>
Date: Thu, 21 Aug 2003 00:30:52 -0500

Hi,

Just to amplify on one point made by Henrik:

 > succeeding in its next registration attempt.

A good way to think about this problem is to realize that the FA is
keeping state (look at Appendix E): there is the global list of
challenges and then there is the per-MN data structure that includes
one unused challenge per MN.  If we ever allow unauthenticated
messages (such as ordinary solicitations or bogus Registration
Requests) to trigger a modification of this state, then we are in
trouble.

-Pete