 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hello Pete,
More responses inline...
Thanks,
Jayshree
> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, September 03, 2003 11:21 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
[...]
>
> > > > 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?
[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.
[...]
> >
> > > > 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.
>
[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 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. Anyway, this is implementation specific also.
>
> -Pete
>
>