Subject: [Mip4] Re: [Issue 44] RFC 3344 - Source Address of the RRQ

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 Mar 2004 15:52:20 -0800

Hello Sri,

This is regarding the new Issue 44.  It seems that we both
tried to insert this issue at about the same time, so that
your text appears twice.  Or else, I don't understand just
how the darned issue tracker works...

Anyway. here is the text revision I propose to
resolve this issue:

Old text:
    The foreign agent's address on the interface from which
    the message will be sent.

New text:
    The care-of address offered by the foreign agent for 
    the mobile node sending the Registration Request.

I believe it's possible for the foreign agent to offer
a multiplicity of care-of addresses, and I tried to
arrange it so that this text does not preclude that
possibility.

Regards,
Charlie P.

ext Sri Gundavelli wrote:
> 
> RFC 3344:
> Section 3.7.2.2. Forwarding a Valid Request to the Home Agent
> 
> "Specific fields within the IP header and the UDP header of the
>    relayed Registration Request MUST be set as follows:
>       IP Source Address
>                The foreign agent's address on the interface from which
>                the message will be sent."
> 
> Per the above the text, the foreign agent is required to send the RRQ
> with the source address of the outgoing interface and this essentially
> conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the
> foreign agent is required to set the source address of the RRQ to its
> care-of address, so that the home agent does not detect NAT incorrectly.
> The logic of NAT detection at the home agent is by comparing the source
> address of the RRQ to the care-of address in the RRQ's MIP header. So,
> we need to fix the text in 3344. There is no reason why the foreign agent
> MUST set the source address of the RRQ to the IP address of its outgoing
> interface. We should infact enforce the foreign agent to set the source
> address of the RRQ to the FA care of address.
> 
> Sri/

-- 
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: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 Mar 2004 16:41:14 -0800

Hello again Sri,

Thanks for submitting this issue.  I think it points to
several revisions that are needed to rfc3344bis.
For a good resolution, I think it helps if we specify
that the source address of the RREQ is the care-of address
offered by the foreign agent, so please assume that for
my discussion below.

>  Issue: When the mobile node deregisters using the care-of address of
>  a different foreign agent than the foreign agent forwarding the dereg
>  request, the document is not consistent in its explanation as how the
>  HA and FA should handle such requests.

Unfortunately true.

>  Also, if the foreign agent is allowed to forward such requests, there
>  is no explanation as how the home agent should locate the security
>  associations for that FA and validate the FHAE.

Presumably, this depends on the address used by the
foreign agent.  Let's say it's the care-of address.
Also, please note that the document doesn't have much
to say about mobility security assocations except in
the case of the mobile node.  It is expected that the
home agent knows how to apply whatever algorithm has
been preconfigured between itself and the foreign
agent, which is not hard to imagine.  We might as
well go one step further and assume that the
mobility security association depends on the
foreign agent's care-of address, and that home
agent uses that address to index into its security
database along with the SPI as presented by the
foreign agent.  In fact, I believe the SPI itself
"should" be sufficient for the purpose, but we
don't have to hold the Mobile IP document up while
waiting to resolve _that_ point.

>  Section: 3.8.2.2. Accepting a Valid Request
>
>     In all cases, the home agent MUST send a Registration Reply to the
>     source of the Registration Request, which might indeed be a different
>     foreign agent than that whose care-of address is being
>     (de)registered.  If the home agent shares a mobility security
>     association with the foreign agent whose care-of address is being
>     deregistered, and that foreign agent is different from the one which
>     relayed the Registration Request, the home agent MAY additionally
>     send a Registration Reply to the foreign agent whose care-of address
>     is being deregistered.
>
>  Section: 3.7.2.1. Validity Checks
>
>     Requests with the 'D' bit set to 0, and specifying a care-of address
>     not offered by the foreign agent, MUST be rejected with code 77
>     (invalid care-of address).

This documents the inconsistency.

>  When the MN sends a dereg request to a foreign agent with the intention
>  of deregistering its earlier binding it had with a different foreign agent,
>  the behaviour of FA as documented in Section 3.7.2.1 is to reject such
>  requst with invalid care-of address error. However, the HA considerations
>  (Section 3.8.2.2) allows such requests. The scenario is not handled
>  consistently at both HA and FA ends.

Suggested resolution: amend the paragraph in section 3.7.2.1
as follows:

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

This just adds a "nonzero lifetime" conditional which is then
needed to trigger a mandated rejection.

>  Also, if the foreign agent is allowed to forward such requests, there
>  should be some explanation as how the FA should function when it
>  receives a dereg message with "D" bit not set and care-of address
>  set to the MN's home address (Deregister all bindings) or when its
>  set to the care-of address of a different foreign agent. Assuming the
>  FA is allowed to forward such a request and when there is security
>  association configured between FA and the HA, the home agent will not
>  be able to validate the FHAE.

With the above, the FA is allowed to forward the request.  With
the proposed resolution of Issue 44, the IP address in the IP
header will be a care-of address offered by the sending foreign
agent.  Then, the home agent can verify the FHAE, with the above
proviso that the foreign-home mobility security association is
preconfigured just that way.

>                                 The home agent for validating the FHAE
>  first needs to use COA address from the RRQ and use the SPI to locate
>  the security associations. Given that the care-of address is set to
>  either the home address of the mobile node or the care-of address of
>  a different foreign agent, how should the HA validate the FHAE ? The
>  HA cannot use the source address of the RRQ to locate the security
>  associations as there could be NAT in the path.

Well, I guess we are agreeing that the security association used
to validate the Foreign-Home Authentication Extension is indexed
by the source IP address.  That information needs to be supplied
in section 3.5.4.  Here is some proposed text:

   In order to perform the authentication, the Home Agent and the
   Foreign Agent have to have configured a security association that
   is able to be indexed by use of the SPI and the care-of address
   assocated with the Foreign Agent.  This care-of address MUST
   be used as the Source IP address of the Registration Request
   containing the Foreign-Home Authentication Extension.  When
   the extension is used with a Registration Reply message, the
   foreign agent address MUST be used as the Destination IP
   address in the IP header.

Please let me know if I have sufficiently understood the issue,
and if my proposed revisions clear up the inconsistencies.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 13 Mar 2004 18:45:59 -0800 (PST)

Hi Charlie,
            I agree with the proposed text.

Thanks !
Sri.

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 13 Mar 2004 19:09:09 -0800

Hi Charlie,
                 Please see my comments below ...

Regards !
Sri.

> waiting to resolve _that_ point.

I'm not sure if we should just assume the home agent will some
how identify the security association for validating the FHAE. In
this scenario,  the home agent would have no means to identify
the mobility entity that is forwarding the request. Home agent
cannot use the care-of address for indexing the security association
as it is a dereg request from a mobile node for a binding it obtained
thru a different foreign agent. Home agent cannot also use the
source address of the registration request for the security
association lookup, as the address could potentially be a NAT
gateway address,  scenario supported by RFC 3519.

SPI alone is not sufficient for any entity to identify the security
association. It is always with in the context of two entities. If the
home agent cannot always identify the peer using the source
address or care-of address of the dereg request, then the home
agent would not be able to locate the security association.

I agree, it is a difficult problem to solve. But, we have to document
this special case and provide some guidance as how to deal with it.

> needed to trigger a mandated rejection.

Ok. This should fix the home agent and foreign agent behavior
inconsistency with respect to the above problem.

> preconfigured just that way.

The proposed text above (with non-zero lifetime)  fixes the inconsistency.
But, now that the FA is allowed to forward the request, we still would have
the problem of home agent not being able to verify the FHAE in all scenarios.

> in section 3.5.4.  Here is some proposed text:

Not sure. If  the source address is used to index the security association,
for validating the FHAE, it will fail in the NAT scenario.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 15 Mar 2004 12:41:29 +0100

Sri,

Just a small question. Why would the MN send a deregistration for a CoA that
it previously had, instead it should send a registration for the new CoA
which would automatically cause the tunnel to the previous CoA to be
terminated.

This means that the HA will terminate its side of the tunnel towards the old
FA, the old FA must wait for a timeout or if it supports revocation the HA
can send a revocation. This means that the HA can allways use the CoA when
it does a lookup for the SA and then the SPI to find the Security Context
within that SA. As you say, using the source address is not good since there
might be a NAT inbetween.

/Fredrik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sri
Gundavelli
Sent: den 14 mars 2004 04:09
To: Charles E. Perkins
Cc: Naveen Paulkandasamy; [email-masked]
Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a
different careofaddress

Hi Charlie,

Regards !
Sri.

The proposed text above (with non-zero lifetime)  fixes the inconsistency.
But, now that the FA is allowed to forward the request, we still would have
the problem of home agent not being able to verify the FHAE in all
scenarios.

---

From: Naveen PaulKandasamy <[email-masked]>
Date: Mon, 15 Mar 2004 08:30:52 -0800

Hi Fredrik,

please see inline...

>which would automatically cause the tunnel to the previous CoA to be

I think, this is true only for the case where the MN is not requesting 
simultaneous bindings ?

thanks,
naveen.

>>>    source of the Registration Request, which might indeed be a
>>>      
>>>
>different
>  
>
>>> of deregistering its earlier binding it had with a different foreign
>>>      
>>>
>agent,
>  
>
>>> requst with invalid care-of address error. However, the HA
>>>      
>>>
>considerations
>  
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Mar 2004 09:03:13 -0800 (PST)

> I think, this is true only for the case where the MN is not requesting

Hi Fredrik,
            Yes, when the MN has opted for simultaneous bindings and when
it prefers to terminate a particular binding or all bindings from a
foreign location.

Thanks !
Sri.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 15 Mar 2004 14:10:49 -0800

Hello Sri,

> the mobility entity that is forwarding the request.

I think you mean that, the home agent would, in _some_
circumstances, be unable to validate based on the source
IP address in the Registration Request, as you detail
below.  In other circumstances, of course the home agent
would have the means.

>                                                     Home agent

If I understand it, this is the only objection to using the
IP source address.

> association. It is always with in the context of two entities.

Well, there's 4 billion of them, and that ought to be enough
to guarantee uniqueness.  But as I mentioned before, I don't
propose that we need to haggle about this just yet unless no
other way suffices.

> If the home agent cannot always identify the peer using the source

Here is a proposal for further comment.  It might work.

We can specify the following:

- The home agent has to follow special rules in order
  to identify the foreign agent which created the
  data in the Foreign-Home authentication extension.

- This method is only valid for Registration Requests
  with the 'D' bit zero.

- The foreign agent is identified by using the
  "Care-of Address" field in the Registration Request

If this is acceptable (i.e., I didn't miss the point),
I will make the appropriate changes to the text.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 15 Mar 2004 20:41:24 -0800 (PST)

Hi Charlie,
           Thanks for your response. Please see my comments below ...

Regards !
Sri.

> below.  In other circumstances, of course the home agent
Yes. In some scenarios ...

> If I understand it, this is the only objection to using the

Yes

> propose that we need to haggle about this just yet unless no

Sure. It is a big number, but per IP Security Architecture doc,
it is always tied to a peer. I agree, we don't have to delay
the process of 3344bis from becoming a standard, while trying
to fix this Simultaneous binding issue. I'm ok with your text
below. We can always address the FA Identity problem outside
the current draft. FA can always hint the HA by adding certain
Identity extensions along the lines of FA Error extensions.

> I will make the appropriate changes to the text.

Ok ! This works. Thanks for your comments.

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Mar 2004 08:57:44 -0800

Do we need a solution for the case of MN sending deregistration for a
particular CoA?

For registrations, the CoA should be set as CCoA or FA CoA.  But
for deregistratations, maybe we should have an extension that contains
the CoA to be deregistered?  This could be either the selected CoA
(in case of simultaneous bindings), previous CoA, or HoA for all bindings.
This scheme would clearly identify the FA for FHAE authentication
and which CoA(s) the MN wish to deregister.

Basically, this problem existed from Day One (since RFC 2002) and maybe
this is a good time to resolve it?

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Mar 2004 09:14:30 -0800

Hello Kent,

I didn't see exactly what remained to be done.  I'd rather not
make new extensions unnecessarily.

> Do we need a solution for the case of MN sending deregistration for a

It could be that we already have a solution, yes?

> (in case of simultaneous bindings), previous CoA, or HoA for all 

But these cases are already covered, I think.

> and which CoA(s) the MN wish to deregister.

Whether or not the FHAE is applied should be invisible to the
mobile node.

> this is a good time to resolve it?

I thought the problem didn't exist until RFC 3519.

Regards,
Charlie P.

===================================================

> --DS8073626969754241571--
>

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Mar 2004 12:11:58 -0800

Hi Charlie.

I think the issue is how does HA authenticate the FHAE when
MN sends a deregistration message?  HA needs a security association
with the FA, which is typically identified by the CoA (assuming FA
providing service to MN).  The source IP address RRQ from FA is the
transmitting interface's IP address (until RFC 3519).  So an FA with
multiple interfaces would likely use CoA to identify itself for the SA
with HA.  But MN has to set the CoA field to the address used as index
to remove the right mobility binding on HA.  What I meant by Day One
problem is when FA is identified by the CoA field only, which seems
practical.

Maybe I missed the solution that covered this case?

The statement, "The home agent has to follow special rules in order
to identify the foreign agent which created the data in the
Foreign-Home authentication extension.", doesn't provide information
on exactly how the FA is actually identified in the registration
request message.  There are 2 fields, source IP address and CoA,
but neither is sufficient given that source IP address may be NAT'ed
and CoA is what MN wants to deregister.

That was the reason behind proposing some extension to identify
the FA clearly for HA to look up the SA.  I agree that we don't want
to have any unnecessary extensions. :)

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Mar 2004 12:42:51 -0800

Hello Kent,

Now, I see the problem that you were referring to.

Briefly, if the following conditions are met:
- MN is deregistering
- MN is not located at the care-of address
   in the deregistration message, and
- NAT,
there isn't any logical way for the home agent
to figure out what foreign agent is presenting
the FHAE.  For this purpose, we could:
1. use the SPI
2. specify that FHAE is invalid with deregistrations
    from other foreign agents
3. use the FA-NAI extension as specified in the
    Mobile IPv4 Regional Registrations draft which
    seems to be completely done except that it has
    not yet been published ...??
4. make a new extension
5. fuggedaboudit (just kidding)

Is this really a case of interest in practice?
If not, then I would be just as happy with (2)

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Mar 2004 13:03:31 -0800

I thought you were going to be happy with #5.  :)

Going with #2 means that MN would not be able to successfully
deregister any previous CoA.  And because FHAE fails, MN
would not know if the deregistration request got lost instead
and have to retry.

We do have cases in practice when a previous mobility binding needs
to be cleaned up.  Deleting a specific binding is supported by base
protocol.  We shouldn't lose this capability as we add new features
such as RFC 3519.

Use of FA NAI sounds reasonable and generic FA identifier will
come in handy for future features.  I would go for #3, though only
need FA NAI extension.

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Mar 2004 13:16:10 -0800

Hello Kent,

I'd like to discuss just this one point before going
forward:

> would not know if the deregistration request got lost instead

This isn't necessarily true.  We could specify the
following, given that the treatment of FHAE is
completely under control of the Mobile IPv4
document.  For instance, it isn't normatively
dependent on IPsec documents.

Here's a proposal:

- If there is a mobility security association between
  the home agent and the foreign agent, then FHAE is
  required on all registrations with lifetime > 0.
- If the FHAE is present on a deregistration message,
  the home agent has to check it.
- If the FHAE is not present, but the Mobile-Home
  authentication extension checks, then the home agent
  MUST (?SHOULD?) expunge the indicated care-of address
  from its list of care-of addresses registered for that
  mobile node.

Note that the FHAE doesn't seem to be related to the
content of such a deregistration message in the same
way as it might be for a registration message.
If the mobile node wants to discontinue service,
I don't see why a foreign agent in this scenario
should have anything to say about it.  In fact,
maybe we should mandate that the foreign agent
MUST NOT include the FHAE, even if it does have
a security association.  It could be a way to
keep the mobile node paying for service it does
not want.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 16 Mar 2004 14:49:30 -0800 (PST)

Hi Charlie,

Should we not be consistent w.r.t adding FHAE extensions
for all registration requests irrespective of the lifetime ?
With the above reasoning, we may not need FHAE at all. There
will always be a need for the FA to protect the extensions
it adds to the registration requests and so skipping FHAE
for dereg messages in one scenario may not be such a good
idea, IMHO.

Sri.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Mar 2004 15:11:52 -0800

Hello Sri,

> for dereg messages in one scenario may not be such a good

My reasoning was that in this scenario, the foreign agent
does not necessarily have any authority over the treatment
of the care-of address.  Thus, the home agent has much
less reason to authenticate the foreign agent.

When the foreign agent purports to own the care-of address,
I can see why the home agent would want to be more
careful about the registration process.

Don't you agree there is a difference?

Regards,
Charlie P.

---

From: Pete McCann <[email-masked]>
Date: Tue, 16 Mar 2004 19:52:40 -0600

I think we are going down a rat-hole here for the sake of a corner
case.

I would rather not make extensive changes to our core Mobile IP
protocol simply for the sake of NAT traversal.

It seems that de-registration is a special case where the FHAE is of
less importance.  That is, the FA should not prevent a de-registration
from taking place.

Note that the "D" bit only determines whether the MN is doing
de-capsulation, not whether the registration request traversed a
foreign agent (you can register with an FA even in co-located CoA).  I
am not sure if this point is getting glossed over in the discussion
below.

Perhaps the right approach is to specify the FA MUST NOT append FHAE
when the lifetime=0, as Charlie suggested earlier in the thread.
Also, the HA MAY/MUST ignore any such FHAE, assuming it can
independently verify the MHAE in the same message.

Alternatively, maybe we should encourage de-registrations to go
directly from the MN to the HA, ignoring the 'R' bit from agent
advertisements.

-Pete

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Mar 2004 19:26:57 -0800

Not to be nit-picky...  NAT traversal is a common scenario.  Base
protocol supports deregistration using FHAE assuming FA is
identified by source IP address instead of CoA.  Deregistration of
previous binding is needed for simultaneous bindings or load
balanced bindings.  IMHO, using an FA NAI extension doesn't
seem to be extensive change, and generally useful to identify the
FA clearly for FHAE and MFAE authentications.  The CoA field
is not sufficient since Day One to identify the FA.

FA would not be preventing deregistration if it can identify itself
in the registration message.  :)  In general, it seems that FA uses
FHAE to protect the communication channel between FA and
HA regardless what is exactly in the details of the message.
Does having a special case to bypass the security association
between FA and HA create new security holes?  Is there a
guarantee that all deregistrations today and in the future will
not require authentication check?

BTW, we have also thought of FA not adding FHAE for deregistrations
and/or HA not processing FHAE too.  But seems like there is some
reason that administrator set up the SA between HA and FA, and
bypassing that doesn't make us comfortable.  And this special case
would have to be considered for each enhancement we make to
Mobile IP to access any security implications.  It saves us some
time now, but may cause more cumulative cycles afterwards in
future ideas and drafts.

Not to gloss over the R-bit issue.  Another reason to clearly identify
the FA so HA can authenticate FHAE using the right SA, IMHO.  As
for the idea of MN deregistering directly to HA by ignoring the R bit,
I think the R bit would need to be enforced by the FA if it is
advertising mandatory registration via the FA.  If it's purely voluntary,
MN can always bypass and the R bit has no effect.  But if there is
filter to prevent direct registration by MN, then encouragement to
bypass the FA for deregistration won't work as such filters don't
check on the content of the message.

Sorry, not meaning to continue the rat-hole, but wanted to provide
some reasons why eliminating FHAE may work against the wishes
of the administrator who created the SA between the HA and FA.
Might also create a loophole for oversight in future FA-HA extensions
as well.  Anyways, looking for a good solution to this issue so we
can resolve and move on..

Kent

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Mar 2004 19:41:38 -0800

Hi Charlie.

I thought #2 meant going with existing operation.  I agree that FHAE
behavior is in our hands.  :)

Comments below.

>   the home agent has to check it.

This will likely cause the authentication to fail.  Let's say that admin set up
SA between HA and FA (either manually or AAA).  The FHAE will be
appended to the deregistration since FA can index the SA based on the
HA field.  But HA can't identify the FA to retrieve the right SA for 
authentication.

>keep the mobile node paying for service it does

The FA wants to add the FHAE because it wants to secure the
messages between itself and HA.  There may be some extensions
that FA adds which are relevant to the mobility binding.  Avoiding
FHAE seems to be a hack, IMHO.  The root cause is lack of
FA identifier to satisfy authentication process.  Should we solve
the problem by clearly identifying the FA using either the FA NAI
or new extension (when CoA is insufficient)?

Another value is that such extension and the CoA fields are protected.
The source IP address is not, but the value of protecting the identifier
can also be debated.  :)

Kent

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Mar 2004 23:50:06 -0800

Hi Charlie.  Sorry for being late in this thread.

Should we be more specific here?  As you said, the FA may
offer multiple CoA's.  The MN chooses the CoA in the RRQ.
It's important to RFC 3519 that this source IP address is
consistent with the CoA in the RRQ.

Possible text:

     Copied from the Care-of Address field within the Registration
     Request.

This might be a bit more detail and accurate to support?

Kent