Subject: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE

From: Kent Leung <[email-masked]>
Date: Mon, 14 Mar 2005 11:19:29 -0800

Hi folks.

I'll try to summarize to see if we can reach some closure on this
issue.

This is the scenario when the problem is encountered.

MN is registered to the HA and moves to a new FA.  The new FA
is somehow misconfigured with the wrong SA with the MN's HA.
This invalid SA means that any registration between FA and HA
will not work because authentication fails.  Just to note that if the
SA is valid or if there is no SA, then everything works fine.

The issue arises when MN deregisters on the new FA which has
an invalid SA with the HA.  The deregistration will not work.

I've maintained that in this scenario, MN will not be able to register
as well.  So it's a configuration error that needs to be fixed as
the security relationship between FA and HA should be upheld.
The FA is configured with FHAE and always add extension to
the RRQ directed to the HA.  HA always authenticate FHAE.  The
security logic is clear, authentication of message exchange between
FA and HA are provided when FHAE service is configured or set.

Charlie feels that this deregistration has nothing to do with the FA
so should not be prevented due to some misconfiguration on the
FA or HA.  To get around the security relationship, check certain
fields such as lifetime, care-of address, D-bit, etc. on the FA
(to decide if FHAE should be added) and HA to figure out the
intent of the RRQ.

Since I get to summarize, I'll add one more point.  :)  I believe that
we should be fine with specification that is simple and clear
for security relationship between FA and HA.  And if real deployment
problem is encountered by operators/customers, _then_ we can
add more logic to support specific scenario.  For now, please just
keep it straightforward.  Thanks.

Kent
--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 Internet Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.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: Mon, 14 Mar 2005 12:53:46 -0800

Hello Kent,

I feel that the summary has been worded to presuppose
a particular resolution.  I'll point out these places below.

> is somehow misconfigured with the wrong SA with the MN's HA.

Check.

> will not work because authentication fails.

Not necessarily!  This outcome is what needs to be prevented.

> an invalid SA with the HA.

Check.

>   The deregistration will not work.

Not necessarily!  This outcome is what needs to be prevented.

> the security relationship between FA and HA should be upheld.

But it could well be that the MN doesn't want to register anyway.
It might just want to save some money by deregistering.

> the RRQ directed to the HA.

Not necessarily!  This outcome is what needs to be prevented.

> HA always authenticate FHAE.  The

It's fine for the home agent to check the authentication.  What is not
fine, is for the home agent to fail to deregister the mobile node's previous
care-of address.

> FA or HA.

Check.

> To get around the security relationship, check certain

The words "get around" presuppose a particular outcome that we
are trying to avoid.

> for security relationship between FA and HA.

Check.  In particular, it should avoid this deregistration problem.

>   And if real deployment
> add more logic to support specific scenario.

O.K.  Let's interpret this sentence to mean the following:

Allow the deregistration, and if real deployment shows any
problem with the FA when the mobile node wants to deregister,
then we will add more logic.

> For now, please just keep it straightforward.  Thanks.

Check.

Let's keep it straightforward.

Mobile node authenticates   ==>  home agent acts on its
verifiable request.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Mon, 14 Mar 2005 13:05:49 -0800

Hi Charlie.  Thanks.  We have now articulated the 2 different
approaches.  I believe we both agree on one thing - closure on
this issue.  :)

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 15 Mar 2005 01:20:31 +0100

Hi Kent and Charlie,

    Below I attach Pete's writeup of the different combinations of
SA selectors we could use to express your respective 2 approaches.
Could you please check through the writeup, and indicate your
preferred selectors in terms of the a) to f) selectors in
Pete's note, (or add other's, if there are more than a) to
f) to consider), so we are clear here on exactly what is being
proposed.  

With that in hand I'll ask the people on the list to please weigh
in with considered opinions, so we can (hopefully) find a consensus
position regarding this, and close it.

	Henrik

> At 12:53 PM 3/14/2005 -0800, Charles E. Perkins wrote:
[...]

On 2005-02-25 10:47 pm Pete McCann said the following:
> Hi, Henrik,
> 
> I went back and reviewed the archives.  There are a lot of complex and
> thorny issues here.

[...]

> Whatever selectors we choose, it is important to understand that they
> serve two purposes:
> 
> 1. The sender of a message must find the right SA with which to
>    compute the authentication extension, or determine that an
>    authentication extension is not necessary.
> 
> 2. The receiver of a message must find the right SA with which to
>    check the authentication extension, or to determine that a message
>    without an authentication extension should be dropped.
> 
> Both ends of the selector computation must be done in exactly the same
> way to guarantee interoperability.
> 
> I would say that we need to choose some subset of the following fields
> as the selector set:
> 
> Possible Registration Request Selector Fields
>   a) The Source IP address
>   b) The Destination IP address
>   c) The Care-of Address
>   d) The Home Agent Address
>   e) The Lifetime field (or a bit which says whether or not it is zero)
>   f) The D bit (set to 1 if co-located CoA is being used)
> 
> Current status quo in the 3344bis text is, I believe, (c,d) with a
> proposal from Charlie to add (e).
> 
> Now, before we consider adding (e) I think we need to get our story
> straight on why (c,d) is such a good choice.  I have already pointed
> out the difficulty with (c,d) when using co-located CoA registering
> via the FA (which may or may not be using the 'R' bit).  A possible
> solution to this difficulty is to configure duplicate SAs at every
> possible legal value of (c,d) (i.e., all CoAs 'c' that could be used
> from a given FA) but this seems like way too much state and doesn't
> handle the case where more than one FA are deployed on a given link.
> 
> Another possible approach is to go back to using (a,d) instead of
> (c,d).  Of course, NATs can change the value of (a) and so this is why
> 3519 mandated (c,d) and a=c.  However, my understanding is that most
> current implementations (those that don't do 3519) actually use (a,d)
> even though this has been ambiguous ever since RFC 2002.  (a,d) seems
> to be the most straightforward approach and matches e.g., IPSec style
> processing.
> 
> I have proposed on the list a possible fix to the NAT issue where
> duplicate SAs are deployed at every possible legal value of (a,d)
> (i.e., all NATs that could be on the path between a given FA and HA)
> but this is a bit of an administrative overhead and doesn't handle the
> case where more than one FA is deployed behind the NAT.  Another
> possible approach is to bury our heads in the sand while uttering some
> wistful complaint about the never-ending stupidity of NATs.  I make it
> sound silly but it is actually my personally favored approach.
> 
> Now, as I understand it, part of the motivation for adding (e) was to
> handle the case when the selector was (c,d) and the CoA 'c' in
> question nevertheless did not belong to the current FA.  We really
> should nail down the question of whether we are going to revert back
> to (a,d) before debating whether to transition to (c,d,e).  Agreed?
> Furthermore, if we do transition to (c,d,e) wouldn't we sometimes want
> an FA-HA authentication extension for (c,d,0)?
> 
> In summary, I do not see a clear winner here.
> 
> 
> 
> Note that for Registration Replies our choices are a bit different as
> the CoA is not represented in the message:
> 
> Possible Registration Reply Selector Fields
>   w) The Source IP address
>   x) The Destination IP address
>   y) The Home Agent Address
>   z) The Lifetime field (or a bit which says whether or not it is zero)
> 
> I assume that most implementations today use (x,y).  Note that in this
> case the NAT issue boils down to modifying 'x' not 'w' because this is
> a response that trickles back through the NAT state set up by the
> request.  How does 3519 handle this case?  It seems like the HA has to
> find the SA based not on the contents of the outgoing message but
> based on the fact that it is a reply to a request and there is a
> corresponding SA pair in place that are bound together with
> administrative provisioning.  Processing on the FA seems similarly
> bound up in the outstanding Request state, at least in the case of
> multi-interfaced FAs with different security policies for each
> interface.
> 
[...]

> -Pete