Subject: [Mip4] New revision for rfc3344bis document

From: "Charles E.Perkins" <[email-masked]>
Date: Mon, 10 May 2004 11:08:14 -0700

Hello folks,

I have created a new revision of the rfc3344bis document,
and I would like to submit it soon to the Internet Drafts
directories unless there is a good reason for holding it.

The outstanding issues have been resolved except for
possibly issue #45, but even so it is useful to have
a new revision submitted for consideration.  In this
e-mail, I will describe the current changes which
have been made to the specification in a proposed
attempt to resolve issue #45.  If more text is needed,
another document revision will be created, hopefully
before the meeting in San Diego.

In order to prevent a rogue foreign-agent from
denying a mobile node's deregistration by simply
attaching a bad Foreign-Home authentication extension,
the home agent is now mandated to ignore such
extensions when applied to a deregistration message
(i.e., zero lifetime).

For this a new paragraph has been added to section 3.8.2.2:

   A deregistration which is passed through a foreign agent which is
   different from the the one whose care-of address is being
   deregistered MAY add a Foreign-Home Authentication Extension to such
   a deregistration.  However, as this deregistration concerns a
   different foreign agent than the one whose authentication extension,
   the home agent MUST disregard the Foreign-Home Authentication
   Extension of such a deregistration.  The remaining validity checks,
   as described in Section 3.8.2.1, are required in full.

This requires a change to section 3.8.2.1, bullet item (c), first
sentence to now read: 

      c) If the home agent shares a mobility security association with
         the foreign agent, and this is a registration request (has
	 non-zero lifetime), the home agent MUST check for the presence
         of a valid Foreign-Home Authentication Extension.

In section 3.7.2.1, first sentence, clarification about when
code 77 is valid:

      Requests with the 'D' bit set to 0, nonzero lifetime, and
      specifying a care-of address not offered by the foreign agent,
      MUST be rejected with code 77 (invalid care-of address).

Thanks to Henrik for fashioning the above text replacements
and additions.

Regards,
Charlie P.

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 10 May 2004 23:53:21 +0200

Hi Charlie,

    Thanks for creating a new revision of rfc3344bis.

One correction:

>    as described in Section 3.8.2.1, are required in full.

I think that had better be:
	s/whose authentication extension,/whose authentication extension is added,/

This blunder was in the text I sent you, and not due to any editing miss
on your part.

	Henrik

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 14 May 2004 00:29:53 -0700

Hi Charlie,
                  Since we all agreed to use explicit FA Identity extension in the
Registration Requests from the foreign agent to the home agent for notifying the the
care-of address, we should probably remove the MUST clause from the following text and
allow provision for using the Identity extension as a means to validate the FHAE.

Thanks !
Sri.

> home agent MUST disregard the Foreign-Home Authentication

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 14 May 2004 09:56:41 +0200

Hi Sri,

    I'm adding [Issue 45] to the subject line to have this picked up by
the Issue tracker and archived for this issue.  More inline:

> allow provision for using the Identity extension as a means to validate the FHAE.

I believe that if you go over the entries in the issue tracker for issue
45, you'll find that it's far from clearcut that we have consensus on a
resolution; so you'r statement "we all agreed to use explicit FA Identity
extension" above doesn't quite hold up.

More below.

....
> >         s/whose authentication extension,/whose authentication extension is added,/
...

If you find the above proposal unsatisfactory, it would be good if
you could propose some alternative text.

But I think it would be good to keep in mind that:

    1. The proposal above works also in the case of an old unmodified FA.

    2. Adding dependency on a new  draft may in the best case delay 
       3344bis half a year, in the worst case prevent it from advancing
       from Draft to Proposed standard at all.

	Henrik

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 14 May 2004 01:18:21 -0700 (PDT)

Hi Henrik,
           Comments inline ..

>        from Draft to Proposed standard at all.

Sure. We agreed not to hold the current draft and I'm not asking for the
extension to be added to this draft. Sorry, if I was not clear on that. My
only point is to change the "MUST" clause on HA behaviour with respect to
the FHAE validation. The "Mobility Identity Extension" draft we published
today can potentially address the FHAE issue ONLY if HA is not forced to
ignore the FHAE validation in the above scenario. May be all I'm asking is
to leave the above text with the "MAY" clause and that would not have any
impact on the old FA scenarios.

Regards !
Sri/

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 14 May 2004 10:36:48 +0200

Hi Sri,

> impact on the old FA scenarios.

Ok, I see.  My thoughts were that you could let the new draft amend
3344bis on this point, saying in effect something like this in the new
draft:

...if the FA uses a FA identity extension to identify itself and its
authentication extension, as described in this draft, and the HA understands
the FA identity extension, the HA no longer must disregard the authentication
extension from the FA as described in [3344bis], but on the contrary SHOULD
verify the FA authentication extension using the FA identidy from the FA
identity extension...

	Henrik

---

From: Pete McCann <[email-masked]>
Date: Fri, 14 May 2004 10:39:28 -0500

I'm ok with relaxing the MUST disregard to a MAY disregard; however, I
am not sure that adding FA NAI extension would turn this into a MUST
verify before processing de-registration.  It seems like the HA would
always honor a valid de-registration request that passed end-to-end
replay protection, no matter what extensions or authenticators were
added by the FA.

Maybe we need to take a more nuanced approach than all-or-nothing
success/failure.  Maybe we should view the FHAE as protecting only the
extensions added by the FA, and possibly the care-of address owned by
that FA if the request has lifetime > 0.

One thing we might be missing in all of the discussion on identifying
the FA: an important part of indexing a security association is not
just so that you can find it when you are checking an existing
authentication extension, but also so that you can detect when it is
missing in a message received from another entity.  The FA NAI, by
itself, cannot be the only index key to the SA table, because we also
need to be able to discard messages (or ignore certain parts of
messages) that are not protected by an authentication extension when
they really should be, according to the IP source address / care-of
address.

-Pete

---

From: Kent Leung <[email-masked]>
Date: Fri, 14 May 2004 22:13:30 -0700

I believe that no security association between peers should be compromised.
Maybe I missed it, but don't remember any consensus to put such text
to disregard Authentication Extension.  Actually, I think there was some
agreement that FHAE (or any AEs for that matter) should not be
simply ignored.  (I know I've been vocal in my disagreement about
ignoring FHAE - sorry AEs should not have special cases for handling;
either one is trying to secure or not. :)

See Issue #44 Comment #149:
>I think your response last week convinced me that ignoring the R
>bit is not a good idea, and I agree that the HA should check the FHAE,
>if it is present, and discard the message if it doesn't check.

RFC 3344bis should probably not mandate changes to current
implementations.  Thought there was already agreement that Mobility
Entity Identify extension is needed for accurate identification, which is
the root cause of issues #44 and #45.  So that would
solve the problem cleanly and not bypass any security associations
which are set up by administrators.  And there was agreement that
another draft will handle this.

See Issue #44 Comment #149:
>If someone wants to put together a new document on Mobility Agent
>Identifier extensions I think that would be a good idea.

See Issue #44, Comment #142:
>Your argument below is persuasive.  It seems to me this would be a
>fairly clean solution which leaves 3344 as flexible as today, improves
>NAT traversal and solves the deregistration FHAE problem.

In addition, I would expect that any messages received without proper
AEs would be discarded.  For example, the source IP address or CoA
that matches an FA SA in a message that does not contain FHAE
would be discarded by the HA for failing authentication.  With the new
draft, the Mobility Entitiy Identifer would be used to index an FA SA.

In summary, I propose removing any text related to the issue in
RFC3344bis because current implementation is right in terms of
identifying the FA by source IP address or CoA.  Future implementation
should follow the upcoming draft that identifies FA accurately and solve both
problems cleanly.  Having any text that specifies to not add AE or ignore
AE is more damaging than leaving issues as status quo to be dealt with
later, IMHO.

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 15 May 2004 09:44:08 +0200

Hi Kent,

I'm not adverse to your reasoning here.  However, two points:

1. If we say nothing about this in 3344bis, then we still have the basic
issue unsolved, and no indication that it even exist, in 3344bis.  

2. The end result of leaving things as they are for now is that an FA is
able to block the deregistration of a CoA belonging to another FA - i.e. 
a CoA for which it has no authority.

Considering these points, could you suggest some alternative text, please?

Or do you feel really strongly about not even mentioning the issue in
3344bis?

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 15 May 2004 09:59:09 +0200

Hi Pete,

> replay protection, no matter what extensions or authenticators were

How about SHOULD disregard?  As for the MUST verify, I don't feel
particularly strongly about that.  However, see Kent response - there
are other opinions.

> that FA if the request has lifetime > 0.

Makes strong sense to me.

> they really should be, according to the IP source address / care-of

Good point.  

Starting to think about this, I get the feeling we need a combinatorial
state table here, to cover all the cases of source/care-of address and
how they should be handled, to make sure we're not missing something.
Maybe we could suggest including such a table in the
draft-sgundave-mip4-identity-ext-00.txt? :-)

	Henrik

---

From: Pete McCann <[email-masked]>
Date: Mon, 17 May 2004 00:04:17 -0500

Hi, Kent,

Yes, I can see how special-casing the FHAE would be difficult in most
implementations.

However, I agree with Henrik & others that there is a subtle problem
here, and now I don't think it can be fixed with an FA NAI, due to the
missing auth extension detection problem.  If attackers would just
cooperate and set the "evil" bit in the packet headers our job would
be a lot easier.

Reading your mail, I think you are suggesting to index the SA by
*both* FA source IP address and FA COA.  Is that explicit in the
current draft?  If not, it should be.

We may have slightly differing views on the current problem we are
trying to solve.  Let me try to state it a couple of different ways
and see if you agree:

* An MN is trying to de-register an old care-of address through an FA
  that is behind a NAT.  The FA thinks it has an SA with an HA, so
  appends FHAE.  Unfortunately, the HA can't find it due to the NAT
  and so drops the message.

Now, it seems that FA NAI would fix this problem.

However, let me state another problem:

* An MN is trying to de-register an old care-of address through an
  FA that is behind a NAT.  The FA doesn't have an SA with an HA, so
  does not append FHAE.  Unfortunately, the HA looks at the COA in
  the message, realizes that it has an SA with the old FA, and so
  drops the message.  Note that source IP address is not useful
  for identifying the FA because of the NAT.

Now, it seems like FA NAI would not fix this problem, because there is
no way to tell whether or not an un-authenticated NAI was inserted by
an attacker after stripping out the real NAI/authenticator extensions.

So, it seems like we at least will end up needing special rules for
how to index the SA in the case of de-registration.  That is, we might
look for SAs based on source IP address, COA, and/or FA NAI in the
case of registrations, but with de-registrations, we can't use the
COA.  We might still be able to use the other two items.

Is that accurate?

-Pete

---

From: Kent Leung <[email-masked]>
Date: Sun, 16 May 2004 23:38:39 -0700

Hi Pete.  Comments below.

>current draft?  If not, it should be.

It is not explicit as far as I'm aware of.  Exactly how the FA is identified
is not clearly defined.  I've always assumed both fields are used since
CoA was not always the right identity for FA.

>Now, it seems that FA NAI would fix this problem.

Yes.

>   for identifying the FA because of the NAT.

But, FA should be appending the FA NAI ext to identify itself since the
CoA nor the source IP address is insufficient. This new extension is
providing identity for source endpoint of the message and allow the
receiver side to detect if NAT occurred, SA checked, and any future
operations needed.

>an attacker after stripping out the real NAI/authenticator extensions.

Hmm, not totally clear about this scenario.  Are you saying that the
attacker can modify fields in the message in transit to cause failed
authentication?  But it would be easier just to change one bit anywhere
before the MHAE?

As for how to avoid un-authenticated FA NAI, one method is to advertise
this identity to the MN so it gets protected by the MHAE?  This can be
dealt with in the new draft.

>COA.  We might still be able to use the other two items.

I think we can have consistency for registration and de-registration by having
the FA to always insert the FA NAI in the message when the source IP
address or CoA is insufficient.  The FHAE is appended only if FA has an SA
with the HA.  The HA will know which FA is the sender and act in a clear
manner to process the message.

As for logic for determining when CoA is insufficient, either when FA is behind
NAT (source IP address will be translated), or CoA in message is not advertised
by FA or match FA's identity, comes to mind...

Kent

>  > > >  > > extension to be added to this draft. Sorry, if I was not 
> clear on
>  > > > that. My
>  > > >  > extension from the FA as described in [3344bis], but on the 
> contrary
>  > > > SHOULD

---

From: Kent Leung <[email-masked]>
Date: Mon, 17 May 2004 00:07:16 -0700

>issue unsolved, and no indication that it even exist, in 3344bis.

Yes, the problem exists.  Saying nothing or describing the problem in
3344bis will still result in having issue unsolved, right?  The dilemma is
if we describe the problem, can we just leave it as unresolved until
another draft?

>a CoA for which it has no authority.

Sorry, I just don't see that "FA is able to block ..".  I see communications
between FA and HA that should be secured by FHAE, and the lack of
identifier of the source of message.  FA is not deliberately trying to sabotage
the deregistration, just that we have not provided the capability to secure
the exchange.

>Or do you feel really strongly about not even mentioning the issue in

There is a problem, but there's been agreement not to provide solution in
3344bis.  I don't have problem with text describing issue.  But if you feel
that it's sufficient just to provide description and no solution, then I can
propose some text.

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 17 May 2004 11:21:39 +0200

Hi Kent,

> the deregistration, just that we have not provided the capability to secure

I'd like to explore this a bit more - when you say you don't see... above,
do yoou mean that you don't agree that the current FA (behind NAT or
sending from a different address than the CoA of the MN) under the
current rules can make it impossible to de-register an earlier care-of
address belonging to another FA - if there is a security association
between the current FA and it inserts an FHAE in the message trying to
de-register the old CoA?

- or do you mean simply that you're not bothered by this ability to block
the de-registration?

> 3344bis. 

No, I don't think we have any clear agreement at all yet ;-)

> I don't have problem with text describing issue.  But if you feel

No, I personally don't think it's sufficient to just provide a description
and no solution in 3344bis, but that wasn't so much the point I was getting
at here...

I think that we need to move forward, so if you object to a proposed text
(and I don't claim the text I proposed was necessarily perfect ! :)  it
would be good if you could propose some alternative text.

	Henrik

---

From: Charlie P <[email-masked]>
Date: Mon, 17 May 2004 11:29:01 -0700

Hello folks,

I agree that it's inappropriate to specify in rfc3344bis
that one should "ignore" the FA-HA security association.
And, yet, I think it's clear that the FA shouldn't be
able to "invalidate" the mobile node's deregistration.

I'd like to suggest a possible (perhaps temporary)
resolution.  What if we point out the problem in the
specification, near the text preventing the invalidation,
and specify that the inconsistency MUST be logged
and alarmed at the home agent?  I think it's clear that
in this scenario something has gone wrong which
cannot easily be fixed by protocol.

Regards,
Charlie P.

I agree that it's inappropriate to specify in rfc3344bis
that one should "ignore" the FA-HA security association.
And, yet, I think it's clear that the

---

From: Pete McCann <[email-masked]>
Date: Mon, 17 May 2004 15:24:25 -0500

Hi, Kent,

 > CoA was not always the right identity for FA.

In fact, I think the source IP address has to be the main identifier.
That is how all the other SAs work and it would be consistent with
your "flat" definition of a Mobile IP SA.  At best, the CoA is just an
auxiliary piece of information that we may or may not keep as part of
the SA, as something that the FA may be authorized to use from the
HA's perspective.

 > receiver side to detect if NAT occurred, SA checked, and any future

So I think you are saying that 3519 is just broken until we have the
FA NAI extension.  In fact, we would need a 3519-bis that *required*
the NAI extension and *required* HAs to drop registration requests that
appear to be NAT-related but which don't contain the extension.

 > authentication?  But it would be easier just to change one bit anywhere

I am worried about a situation where FAs that support the FA NAI and
nodes that do not co-exist in the network.  There is no way in general
for the HA to tell whether it is talking to an old FA with which it
doesn't have an SA or a new FA with which it does but where an
attacker has stripped off the FA NAI + authentication extension.
It should process the request in the first case but drop it in the
second.  How does it know?

 > dealt with in the new draft.

That might help, and avoids the problem of an attacker stripping it
off after the RRQ is generated.  But, I'm not sure it is a cure-all...

 > manner to process the message.

But do we allow existing 3344-compliant FAs to exist in this universe?
If so, we need to keep the old rules for identifying SAs based on FA
source IP address.

 > by FA or match FA's identity, comes to mind...

Are you speaking about logic on the FA or the HA?  I think the logic
on the FA is easy: if you support FA NAI, then always include it.
Logic on the HA is more difficult, as I believe the mechanisms for
detecting NAT in 3519 are themselves not always 100% reliable (but
maybe someone more familiar with the draft can comment).

-Pete

---

From: Kent Leung <[email-masked]>
Date: Mon, 17 May 2004 15:43:55 -0700

Hi Henrik.

At 11:21 AM 5/17/2004 +0200, Henrik Levkowetz wrote:
>[snip]

I sensed that some folks see that the current FA is blocking the RRQ.  So
just pointing out that FA is doing its job of securing the message to the HA
and we need to define a solution to achieve that properly.

>No, I don't think we have any clear agreement at all yet ;-)

If we can provide a solution in 3344bis, then we can state that Mobility
Entity Identifier extension is used to unambiguously determine the peer.

>would be good if you could propose some alternative text.

I'm not sure if the following text is something you're looking for?

The original text:

Proposed text:

     The home agent needs to clearly identify the foreign agent that sent the
     Registration Request for authentication.  This requires the foreign agent
     to append an extension containing its identity when the Care-of Address
     and source IP address in the message do not provide accurate
     foreign agent identification to the home agent.  However, this extension
     may be appended indiscriminantly by the foreign agent to avoid 
un-ambiguity
     for any condition. The remaining validity checks, as described in
     Section 3.8.2.1, are required in full.

(I've not named the extension as Mobility Entity Identifer type for now)

Kent

---

From: Kent Leung <[email-masked]>
Date: Mon, 17 May 2004 16:30:37 -0700

Hi Pete.

My take is that HA and FA need to identify the source of the message for
authentication.  The identification may be the Mobility Entity Identifer,
source IP address, or Care-of Address.  Once authenticated, the message
is processed in accordance to RFC 3344 and 3519.

I think we should move fast in the WG to come to consensus on having
a Mobility Entity Identifier extension to fix the problem.  We may not run 
into this
problem since FHAE is not common unless within CDMA2000 network.
But in that case, the NAT box is not usually between the FA and HA.

I agree to move forward to closure on this issue.

Kent

At 03:24 PM 5/17/2004 -0500, Pete McCann wrote:

>  > >  > > >  > > only point is to change the "MUST" clause on HA 
> behaviour with
>  > >  > > > respect to
>  > >  > > >  > > the FHAE validation. The "Mobility Identity Extension" 
> draft we
>  > >  > > > published
>  > >  > > >  > > ignore the FHAE validation in the above scenario. May be 
> all I'm
>  > >  > > > asking is
>  > >  > > >  > > to leave the above text with the "MAY" clause and that 
> would not
>  > >  > > > have any
>  > >  > > >  > 3344bis on this point, saying in effect something like 
> this in
>  > > the new
>  > >  > > >  > draft:
>  > >  > > >  >
>  > >  > > >  > authentication extension, as described in this draft, and 
> the HA
>  > >  > > > understands

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 May 2004 20:33:41 +0200

Hi Kent,

> and we need to define a solution to achieve that properly.

Yes.  I think we have a small though basic disagreement on one point - I see
the purpose of the FA using a FHAE as validating and authenticating the
parts of any registration exchange which concerns *that FA*.  If there is a
question of using its resources, it must authenticate that usage.  However,
how do we handle messages from the MN which in no way concern this FA?

I've been considering various options which haven't been mentioned so far,
to my knowledge, like for instance requireing the FA to look at deregistration
messages, and if they concern a  CoA which is not its own, to not sign them.
But this seems still not quite right to me.

Let me test yet another one on you:

The de-registration message in question could just as well have been sent
by the MN from any other address, as long as it's covered by a valid MN-HA
Auth. Ext.  Is there any reason why the MN couldn't send this package as
*data traffic* to the HA, which would de-tunnel it, and route it to itself?

Then the FA (quite rightly) wouldn't see it as a registration request 
concerning itself, to be protected with it's FHAE...

Maybe I'm getting to wild here, but I keep returning to this idea that the
deregistration we're talking about really concerns nobody but the MN and
the HA, and could have been sent from any point really, not necessarily
from this particular FA.

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Tue, 18 May 2004 11:55:25 -0700

The problem with MN sending a data packet to the HA is that
what type of packet is this?  It would have to be an encapsulated
registration request.  But HA doesn't have a tunnel with the MN.
And MN cannot fake the source IP address as the FA's CoA
since the FA may prevent invalid source IP address, as well as
difficulty to map to reverse tunnel in some cases.

You're right that there's a fundamental difference in viewpoints.
I believe that SA between peers is used to protect the exchange
of messages, regardless of the content.  If we provide clear
identification of the peers, this solves the problem simply and
generically.

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 May 2004 20:58:18 +0200

Hi Kent,

Returning to the second part of your message.

>      deregistered MAY add a Foreign-Home Authentication Extension to
>      such a deregistration.  However, as this deregistration concerns
>      a different foreign agent than the one whose authentication
>      extension, the home agent MUST disregard the Foreign-Home
>      Authentication Extension of such a deregistration.  The remaining
>      validity checks, as described in Section 3.8.2.1, are required in
>      full.
>
> Proposed text:
>
>      The home agent needs to clearly identify the foreign agent that
>      sent the Registration Request for authentication.  This requires
>      the foreign agent to append an extension containing its identity
>      when the Care-of Address and source IP address in the message do
>      not provide accurate foreign agent identification to the home
>      agent.  However, this extension may be appended indiscriminantly
>      by the foreign agent to avoid un-ambiguity for any condition. The
>      remaining validity checks, as described in Section 3.8.2.1, are
>      required in full.

Maybe.  As discussed by you and Pete yesterday, maybe this should be
separated as much as possible from 3344bis, and handled as a 3519bis or
completely separate issue, e.g. by the recently submitted draft.  In
that case, I'm thinking that maybe we could describe the problem, but
not solve it:

    There exists a situation where a home agent will have trouble
    correctly identifying the security association to apply to a
    registration request coming from a foreign agent.  This occurs when
    the mobile node attempts to de-register a care-of address it had
    with a previous foreign agent, when the current foreign agent is
    behind a NAT or is forwarding the registration request from a
    different source address than the mobile nodes currnt care-of
    address.  In this case, if the foreign address has a security
    association with the home agent, the home agent will not be able to
    identify the security association, as neither source address nor
    care-of address of the registration request will match the security
    association used by the foregn agent in creating the Foregn-Home
    Authentication Extension.  This may be solved by adding a separate
    foreign agent identification extension to the registration request,
    but this is outside the scope of the current specification.  In the
    absence of some means of correctly identifying the security
    association, the home agent has no choice but to reject the
    registration request, in accordance with the requirements in Section
    3.8.2.1.

Is this a way forward?

	Henrik

---

From: Pete McCann <[email-masked]>
Date: Tue, 18 May 2004 14:02:26 -0500

Hi, Kent,

After thinking about this more, I think it's important that we have
3344bis that works as a standalone document without waiting for any
Mobility Entity Identifier.  So, we need to clarify at least what are
the identifiers for the existing SAs (source IP addresses, CoAs) and
specify exactly what the HA does when it gets a message with a
missing/wrong/broken authentication extension.

Right now, I think SAs between FA and HA are identified by source IP
address, and the action is to drop any message that has a
missing/wrong/broken authentication extension.

For now, we should consider 3519 to update this behavior to allow the
HA to use a different algorithm for identifying SAs.  In this respect,
3519 opens up many security considerations and most of these are
at least listed in 3519.  It may not be possible to fix them, even
with the FA NAI, but at this point I think we need to keep that
discussion separate from 3344bis.  

2794 is an example of a document that updates the indexing of SAs
between MN and HA to use NAI instead of Home Address.  However, in
that document, the Home Address cannot take on any value as it can
with 3519.  So, the security considerations may be different.

Maybe we just have to live with the fact that an MN might be unable to
de-register an old CoA without cooperation of the current FA and a
valid SA between the FA and its HA (having no SA is an example of a
valid SA).  Without such cooperation and valid SA, it is impossible to
fix this problem even with an FA NAI.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 May 2004 21:06:27 +0200

Hi Kent,

> difficulty to map to reverse tunnel in some cases.

This would have to be an encapsulated registration request, sent from
the MNs home address presumably, and you're right, the problem would be
in encapsulating it so that it's seen as data and not a registration
request by the FA.  I'm wondering right now how our (ipUnplugged) HA
would handle IPIP in IP encapsulated traffic coming from an MN...

> identification of the peers, this solves the problem simply and

Yes.  But not in 3344bis.  And also not for legacy systems, but that
may be OK, if we see this as a needed extension for the use of FAs
in a 3519 context.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 May 2004 21:13:47 +0200

Hi Pete,

> missing/wrong/broken authentication extension.

Agree.

Yes.

Yes.

> fix this problem even with an FA NAI.

I agree.  See my most recently proposed text, which I intended to say
bacically this :-)

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Tue, 18 May 2004 12:16:19 -0700

Hi Henrik.  That was what I asked last time - about describing problem
only in 3344bis vs. having some solution.  :)

I've made some minor edits.  Though underlined the part that I'm not
fully clear about.

>     There exists a situation where a home agent will not be able to
>     correctly identify the security association to apply to a
>     the mobile node attempts to de-register a  previous care-of address
>     using the current foreign agent which is
>     behind a NAT device or is forwarding the registration request from a
>     different source address than the mobile nodes current care-of
>     association used by the foreign agent in creating the Foreign-Home

Kent

---

From: Kent Leung <[email-masked]>
Date: Tue, 18 May 2004 12:23:34 -0700

Hi Henrik.  I think we're in agreement about not having a fix in 3344bis.
It's just how to move forward on 3344bis with this problem.  I think the
latest approach is to describe the problem and say that's the way it is,
and will be solved later.  It's not the end of the world that this is not fixed
right now as I've been pointing out as well.  This scenario is a not common
one.  Though some good brain exercise went into providing some good
answers later. :)

Kent

---

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 18 May 2004 12:23:53 -0700

Hello Henrik,

> I agree.  See my most recently proposed text, which I intended to say

If the home agent gets a deregistration, and there
is a Mbbile-Home Authentication extension which
proves that the mobile node wants to deregister,
then I think the home agent has to deregister the
mobile node.  If, in addition to the Mobile-Home
authentication there is a Foreign-Home authentication
that fails, then some action could conceivably be
taken.  I do not see that the home agent should
ever disregard the authenticated instructions of
a mobile node, regardless of the error condition
between the foreign agent and the home agent.

Regards,
Charlie P.

PS. Haven't we all been getting two copies of these
    messages?  I deleted a few CC:'s.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 May 2004 21:34:00 +0200

Hi Kent,

Continuing to refine this,

    There exists a situation where a home agent will not be able to
    correctly identify the security association to apply to a
    registration request coming from a foreign agent.  This occurs when
    the mobile node attempts to de-register a care-of address it had
    with a previous foreign agent using the current foreign agent when
    the current foreign agent is behind a NAT device.  In this case, if
    the foreign address has a security association with the home agent,
    the home agent will not be able to identify the security
    association, as neither source address nor care-of address of the
    registration request will match the security association used by the
    foreign agent in creating the Foreign-Home Authentication Extension.
    This may be solved by adding a separate foreign agent identification
    extension to the registration request, but this is outside the scope
    of the current specification.  In the absence of some means of
    correctly identifying the security association, the home agent has
    no choice but to reject the registration request, in accordance with
    the requirements in Section 3.8.2.1.

I reverted some of the changes - in the case of simultaneous bindings, I
don't think it's quite correct to say that it's a previous care-of
address, while it is a previous foreign agent.

I took out the part you questioned - I think the FA may actually send
from a different address than the care-of address, and this will also
trigger the same problem - but maybe that's making the discussion too
comples.

Hm, wonder where that consistent misspelling of foreign came from - good
catch.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 May 2004 21:48:10 +0200

Hi Charlie,

So, the way I understand you is that you believe the original text I
proposed was OK, while you think the most recent proposal is un-desireable?

As I've tried to say earlier, I think the MNs deregistration of a CoA
with a previous FA is none of the current FA's business, but it seems to
be difficult to find a way of actually accomplishing this without
breaking too much of the security between a FA and HA which have a
common security association.  At least that's the way I understand Kent
here.

I can accept my original text proposal, I can also accept that this
problem is outside of 3344 and thus is mentioned but not solved - but I
*do* wish us to get somewhere with this :-)

	Henrik

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 18 May 2004 19:14:38 -0700 (PDT)

I've posted this ID couple of days back ..., never made it to the WG.
Please post your comments.

Thanks !
Sri

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-sgundave-mip4-identity-ext-00.txt
From: Internet-Drafts at ietf.org
Date: Fri, 14 May 2004 15:39:43 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: <i-d-announce.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe:
<https://www.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=subscribe>
List-unsubscribe:
<https://www.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
Reply-to: internet-drafts at ietf.org
Sender: i-d-announce-admin at ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Mobility Agent Identity Extension for Mobile
IPv4
	Author(s)	: S. Gundavelli, K. Leung
	Filename	: draft-sgundave-mip4-identity-ext-00.txt
	Pages		: 5
	Date		: 2004-5-14

This document specifies a new extension that can be used by any mobility
agent operating Mobile IPv4 protocol in the Mobile IP Registration
messages for offering its identity to the other mobility agent receiving
the message. This is a generic extension that can be used in the
Registration Request or Reply message and can be used by the Home Agent,
Foreign Agent and the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sgundave-mip4-identity-ext-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sgundave-mip4-identity-ext-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sgundave-mip4-identity-ext-00.txt".