Subject: RE: [Mip4] review: draft-ietf-mip4-faerr-01.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 9 Sep 2005 17:58:22 -0700

Hi Gabriel.  Comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of gabriel montenegro
> Sent: Friday, September 09, 2005 10:31 AM
> To: [email-masked]
> Subject: [Mip4] review: draft-ietf-mip4-faerr-01.txt
> 
> I reviewed this draft and had some comments interspersed below. 
> <snip>
> 
> > 7. Security Considerations
> > 
> >    The extension in this document improves the security features
> >    of Mobile IPv4 by allowing the mobile node to be assured of the
> >    authenticity of the information supplied within a Registration
> >    Request.  Previously, whenever the foreign agent was required to
> >    provide status information to the mobile node, it could 
> only do so
> >    by destroying the ability of the mobile device to 
> authenticated the
> >    Mobile-Home Authentication Extension data.
> 
> This *sounds* good, but the next paragraph contradicts it. As 
> I think about this a bit more, one could argue that the 
> opposite effect is true. Suppose the FA has no security 
> association with the MN (the so-called "typical case"
> below). Before this extension, upon receiving a Reg Reply 
> from the HA, an FA could do 2 things:
> 
> 1. relay the Reg Reply as-is from the HA
>    
>    The MN has assurance of the validity of the Reg Reply
> 
> 2. obliterate it and send its own Reg Reply (replacing the 
> HA's code in the
>    Reg Reply effectively means the FA will regenerate and 
> send its own)
> 
>    The MN has no assurance of the validity of the Reg Reply
> 
> Now, in addition to the above:
> 
> 3. the FA can add its own code which cannot be ignored
> 
>   The MN has no assurance of the validity of the (overall) 
> Reg Reply (in the "typical"
> case),
>   cuz even if the HA portion checks out fine, the FA portion 
> cannot be ignored, so the MN is
>   presumably forced to ignore validated information if the FA 
> adds its own non-validated information.
> 
> Whereas before the MN had the ability to validate information 
> in 1 out of 2 cases, the situation is now worse cuz it can 
> only do so in 1 out of 3 cases. If this extension is allowed 
> without any security association (the "typical" case), I'm 
> afraid it worsens matters.
>  

I see this slightly different.  For error condition on the FA, before
faerr draft, #2 happens.  With this faerr draft, #3 happens.  I see that
both #2 and #3 have the same security issue which is unauthenticated
message from FA to MN.  So it's 1 out of 2 before and with FA error
extension.  I don't see the FA extension method as being any worst than
original RFC 2002.

IMHO, what's made worst in this draft is the following statement:

   If a mobile node receives a successful Registration Reply (status
   code 0 or 1), with a FA Error extension indicating that the foreign
   agent is not honoring Registration Reply, the mobile node SHOULD
   then send a deregistration message to the home agent.

This opens up the potential for bad guy to trick the MN to deregister
its session.  Though the security consideration section covers by some
attempt to figure out which reply is from the "true foreign agent".
It's still tricky as the bad guy can send reply with error code when
registration reply is successful, and send reply without error code
extension when registration reply has FA error extension.  Either way,
MN will difficult time to figure out which is real and which is not.

> >    In many typical cases, the mobile node will not have a security
> >    association with the foreign agent that has sent the extension.
> >    Thus, the mobile node will be unable to ascertain that 
> the foreign
> >    agent sending the extended Registration Reply message is the same
> >    foreign agent that earlier received the associated Registration
> >    Request from the mobile node.  
> 
> This basic issue negates the purported benefits of the 
> extension. Should such "typical cases" not be encouraged? 

We can discourage these "typical cases", but the reality is MN-FA SA is
not readily available.  We can encourage the use of RFC 3957 with RFC
3012 to generate the MN-FA SA dynamically whenever possible.  

Another approach to look at this is that the link between MN and FA may
not be that vulnerable to this type of attack.  For example, there are
L2 encryption that protects this path in WLAN and cdma2000 networks. 

> Supposedly, this draft was created primarily for use by 
> 3012bis. 

Although this raised the issue, the problem existed in RFC 2002 when FA
had to reject the request.

> Such usage does not fall under the "typical" case 
> alluded to above, because it requires either an MN-FA 
> Authentication Extension or an MN-AAA Authentication Extension.

This protects the registration request but not the registration reply
assuming MN-FA AE is not available which is still typical.  The MFCE and
MN-AAA AE protects the request from MN to the FA.  But the registration
reply is usually only protected by the MN-HA AE.

> Whereas it is not obvious how the MN-AAA authentication 
> extension would provide any assurance to the MN about the FA 
> (well, perhaps the AAA infrastructure could "vouch"
> for the
> FA to reassure the MN), it seems prudent to impose some 
> security on the use of this extension (as 3012bis requires).
> 

Agree that some security is needed, but it can potentially come from L2?
But then MN and FA need to know if L2 is providing encryption function
and act accordingly.  It complicates things.

> >    Because of this, a malicious foreign
> >    agent could cause a mobile node to operate as if the registration
> had
> >    failed, when in fact its home agent and a correctly operating
> foreign
> >    agent had both accepted the mobile node's Registration 
> Request.  In
> >    order to reduce the vulnerability to such maliciously transmitted
> >    Registration Reply messages with the unauthenticated 
> extension, the
> >    mobile node MAY delay processing of such Registration Reply
> messages
> >    for a short while in order to determine whether another authentic
> >    Registration Reply might be received fromm the true 
> foreign agent.
> 
> s/fromm/from/
> 
> Well, you don't know if it is the "true" foreign agent or yet 
> another bogus reply...
> Again, it seems prudent to require some security association 
> when using this extension (MUST or SHOULD, unlike the current 
> text in which a typical case has no security).
> 

Agree.  But I think we are no worst than when RFC 2002 came out for
dealing with FA rejection of registration requests, _IF_ we don't
require MN to deregister.  The deregistration from MN is to save some
states on the HA and FA.  If we look at this closely, here are the
cases:

1) FA rejects request immediately.  There is no need to deregister as no
states created yet.
2) FA rejects request after receiving reply from HA or binding exists on
HA.  HA has state which will age out or can be deregistered.

For #2, FA can send registration revocation assuming FHAE exists.  This
avoids the pitfalls of unauthenticated messaging between MN and FA to
trigger deregistrations.

If that's not good enough, then here's a wild idea.  What if the
bindings on the HA and FA are set up when MN sends a registration
acknowledgement message after receiving the registation reply?  So, we
have a 3 way handshake.  The binding can still be set up on HA and FA to
providing forwarding function, just removed if registration
acknowledgement is not received shortly.  

I think we shouldn't require MN to deregister unless the registration
reply can be authenticated (MN-FA AE) and that FA should send
registration revocation to HA when FHAE exists but no MFAE exists when
HA has an active binding or successful registration reply cannot be
honored by the FA.

Kent

-- 
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: gabriel montenegro <[email-masked]>
Date: Fri, 9 Sep 2005 23:24:54 -0700 (PDT)

Kent,

Comments interspersed below.

> extension.  I don't see the FA extension method as being any worst than

If M is a bad guy posing as a FA, it now has one more tool in its arsenal,
so I believe things are worse off in the "typical" case of no MN-FA SA.
At any rate, we seem to agree that matters are not better off, contrary to
what the draft claims. This language should be toned down.

> 3012 to generate the MN-FA SA dynamically whenever possible.  

Yes, such language should be added.

> L2 encryption that protects this path in WLAN and cdma2000 networks. 

Depending on your link layer, you may be better off than in the so-called
"typical" case. Such language needs to be added, I'd say.

> avoids the pitfalls of unauthenticated messaging between MN and FA to

Might be better, yes, also saves over-the-wireless link traffic as typically
the FA and HA are on a wired connection.

> HA has an active binding or successful registration reply cannot be

Three-way handshake?

This is too much of a departure. At this point, it seems to me like the
tradeoff given the gain is not worth it, and one could more simply let
the state at the HA expire by itself.

-gabriel

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 18 Sep 2005 19:08:51 +0300

Hello Kent,

I want to revise this document for submission in time for the
next IETF.  So let's try to work towards resolving the issues.

>MN will difficult time to figure out which is real and which is not.
This draft was not written to solve the various problems caused by
malicious pretend-FAs in the neighborhood.  I don't see that any
major new vulnerability is created, given that the malicious FA is already
likely to be able to disrupt the communications quite effectively whether
or not the new error extension is available.

So, let's say for a minute that there is a malicious FA in the neighborhood
of the mobile node, and it can use various tricks to screw up connectivity
for the mobile device.  Then surely it would be a good idea for the mobile
node to get out harms way.  If a malicious FA tricked the mobile node
into sending a deregistration, that would probably be the right thing to do
anyway!  In fact, I'd be surprised if a malicious FA would forward the
deregistration.  If a valiant and proper FA is in the neighborhood trying
to offer good service to the mobile node, we _could_ try to legislate some
behavior to further those good intenions.  For instance, we could say that
a mobile node SHOULD prefer a valid Registration Reply to one that
has an error code in the FAERR extension.  We could say that if a mobile
node receives such an extension with a negative status code, it SHOULD
wait a second to see if a good one arrives.  This wouldn't hurt, because
the alternative would probably take longer than a second anyway.

I agree with your later suggestion to enable the foreign agent to send
a registration revocation IF it has a security association with the home
agent.  I'll probably write some text to support that, along with a new
normative reference to RFC 3543.

Or, you could help by also providing text!  It's always appreciated :-)

>        .........                                     The MFCE and
To be clear, the protection does not depend on the presence
of the MN-AAA extension.

>and act accordingly.  It complicates things.
I do not agree that any additional security is needed, because the point
of the draft is to make things better than in RFC 3344.  It does do that,
without any additional security mechanism.  Moreover, imposing such a
security requirement would render the document useless in many cases
of interest.

Regards,
Charlie P.