Subject: RE: [Mip6] Draft on Securing Home Agent List

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Mon, 11 Jul 2005 15:46:23 +0200

Hi,

The problem with SEND is that it only proves the router has the rights to be a router for some prefixes (linked to the router's certs).
But here, I think, the simplest solution is to use IPsec. Hoping a HA manager knows all his HAs, it is simple to him to set up IPsec between them based on pre-shared keys or certs if SEND is deployed :)

Regards.

JMC.

France Telecom - R&D Division - MAPS/NSS   
Jean-Michel COMBES, Internet/Intranet Security
E-Mail: [email-masked]
Phone: +33 (0)1 45 29 45 94
Fax: +33 (0)1 45 29 65 19
Mobile: +33 (0)6 07 29 30 16 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Radhakrishnan.S
> Envoyé : lundi 11 juillet 2005 15:11
> À : [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Objet : Re: [Mip6] Draft on Securing Home Agent List
> 
> Hi,
>       This draft has brought out an interesting problem. SEND 
> could help solve this problem. So why this method??????
> 
> Anyway, i am posting few comments i have:
> (1) I feel the use of STALE and REACHABLE in places referring 
> to states in both HA List and NCE is little confusing. Maybe 
> use of different words like VALID/INVALID to indicate state 
> of an entry in HA List would be better.
> 
> (2) Sec 3.1
>      " o If the entry exists and it state is STALE then simply ignore
>         this RA message."
> -> Only if RA parameters are identically same with prev one, isnt it?
> 
> (3)  In section 3.1
> -> What about RAs with global address as source address????
> 
> (4)  In section 3.4
> "      o In case the DHAAD reply message becomes more then 
> PMTU then HA
>         must include self Home Agent address. This will 
> ensure at least
>         one valid reachable home agent address"
> -> Very good thought. I feel making it mandatory for the HA 
> to carry its
> address in HA list in DHAAD reply irrespective of message 
> size will guarantee atleast one valid reachable HA. :-)
> 
> (5) What happens in case of a node replying with bogus NA 
> when HA sends NS??? SEND can help in such a case. maybe 
> security considerations section needs to be updated for such 
> a scenario.
> 
> (6) There are grammatical errors at quite few places and 
> missing punctuations.
> 
> Regards
> Radhakrishnan
> ----- Original Message -----
> From: "Sachin" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Sent: Monday, July 11, 2005 5:08 PM
> Subject: [Mip6] Draft on Securing Home Agent List
> 
> 
> > Dear MIP6 Group
> >
> > We have submitted a new internet draft for securing home 
> agent list in 
> > Mobile IPV6. A URL for this Internet-Draft is:
> >
> > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt
> >
> > Technical Summary:
> > The home agent list is learnt by receiving the RA messages. So any 
> > rogue node on the link can send spurious RA on behalf of 
> non existent 
> > nodes. This results in non-reachable and non-existent 
> entries in the 
> > home agent list causing delay in getting service for a MN or not 
> > getting service at all.
> >
> > We are looking forward for your feedback. Thanks in advance 
> for your 
> > kind consideration.
> >
> > Best Regards
> >
> > Mao Shanxiang , Suraj , Deshbandhu &  Sachin
> > (Authors)
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> > 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Jul 2005 14:21:15 -0700

SEND proves its a router, the IPsec SA establishment procedure requires the
HA to present a cert that the host must verify. So there's a filter at both
phases.

That said, I don't think RFC 3775 requires the HA's cert to be annotated
with an attribute saying that it is authorized to act as a home agent. SEND
does allow the router cert to be so attributed (specifically with a list of
prefixes that the router is authorized to route) but it does not require
that.

            jak

----- Original Message -----
From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
To: "Radhakrishnan.S" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 11, 2005 6:46 AM
Subject: RE: [Mip6] Draft on Securing Home Agent List

Hi,

The problem with SEND is that it only proves the router has the rights to be
a router for some prefixes (linked to the router's certs).
But here, I think, the simplest solution is to use IPsec. Hoping a HA
manager knows all his HAs, it is simple to him to set up IPsec between them
based on pre-shared keys or certs if SEND is deployed :)

Regards.

JMC.

---

From: Sachin Dutta <[email-masked]>
Date: Thu, 14 Jul 2005 04:57:18 -0700

HI Jak , Jean and Radhakrishnan,

Thanks for reviewing the draft; I have consolidated the comments, 

> Use SEND

SEND can be an alternate solution but MIP6 implementation should not
mandate SEND to be implemented and link to be secured

The solution suggested is quite simple and does not require much change
and can be used by nodes not implementing SEND	

And Jak I feel for transition scenarios section [8] should be updated
for Home Agent list to have secured and unsecured flag as suggested for
prefix list and neighbor cache by SEND.

And MIP6 to consider secured link and prioritize DHAAD reply based on
these flags

> (1) I feel the use of STALE and REACHABLE in places referring to
states in 
> both HA List and NCE is little confusing. Maybe use of different words
like 
> VALID/INVALID to indicate state of an entry in HA List would be
better.
  Here 

Like in ND on receiving RA, neighbor cache entry created is in STALE
state, same ND logic has been borrowed and extended in HAL. That's why
state has been kept same as ND State as both imply one and same thing 

> -> Only if RA parameters are identically same with prev one, isnt it?

This was kept this was as the frequency of RA messages in MIP6 can be
very fast & processing each RA messages can be an expensive operation
and is a kind of attack only in MIP6. Ignoring that also is not an issue
as RA is periodic & next RA will correct HAL if it was changed
in-between

> -> What about RAs with global address as source address????
Basic ND RFC mandate source of RA to be link local so packet will be
discarded before only

> (5) What happens in case of a node replying with bogus NA when HA
sends 
> NS??? 
ND Protocol issues are not being addressed here and the Security
provided is same as maximum possible on unsecured link. 

I accept the suggestion and will update the security section

> (6) There are grammatical errors at quite few places and missing 
> punctuations.
Will be taken care in the next update :-)

> use IPsec
Not possible, I think JMC already clarified this issue

Please let me know for any other issue

Best Regards,
Sachin

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, July 11, 2005 14:21
To: COMBES Jean-Michel RD-MAPS-ISS; Radhakrishnan.S; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Mip6] Draft on Securing Home Agent List

SEND proves its a router, the IPsec SA establishment procedure requires
the
HA to present a cert that the host must verify. So there's a filter at
both
phases.

That said, I don't think RFC 3775 requires the HA's cert to be annotated
with an attribute saying that it is authorized to act as a home agent.
SEND
does allow the router cert to be so attributed (specifically with a list
of
prefixes that the router is authorized to route) but it does not require
that.

            jak

----- Original Message -----
From: "COMBES Jean-Michel RD-MAPS-ISS"
<[email-masked]>
To: "Radhakrishnan.S" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 11, 2005 6:46 AM
Subject: RE: [Mip6] Draft on Securing Home Agent List

Hi,

The problem with SEND is that it only proves the router has the rights
to be
a router for some prefixes (linked to the router's certs).
But here, I think, the simplest solution is to use IPsec. Hoping a HA
manager knows all his HAs, it is simple to him to set up IPsec between
them
based on pre-shared keys or certs if SEND is deployed :)

Regards.

JMC.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Jul 2005 21:47:16 +0300

I have reviewed this draft.

I agree that the security of the home agents list on the home
link can be a problem.  Or more generally, the security between
the different home agents on the home link can be a problem.

Thanks for writing a draft on this!

I do have some issues with the proposed scheme, however.
Perhaps it would be worthwhile to update this draft to talk
more about the problem, as well as outline a number of
different solutions (not just one) that could be used to
mitigate the problem.

One issue that I have with the proposed scheme is that
it seems equally easy to send a fake RA than to respond to
a NS probe generated as a part of the scheme.

SEND and IPsec were mentioned as potential candidate
solutions in the mailing list discussion. If you look at the
problem from the 10.000 ft viewpoint, its obvious that you
can find many solutions where some additional work by
the network admin will buy better security. The simplest
scheme is perhaps configuring the home agent list in
the home agents directly, and not relying on RAs at all...
at least not for verifying the existence of another home
agent. A slightly more advanced scheme would rely on
SEND, which also requires configuration effort but if
you wanted to do that anyway its not additional effort.
Even more advanced schemes could be devised, perhaps
based on adding home agent authorization information
to SEND certificates, or some sort of a general purpose
security mechanism that secures not only the home agent
list construction but also load-balancing and failover
signaling between home agents. The main questions to
me are how important this problem is, how complicated
mechanism we need to solve it, and whether there's a
need for Mobile IPv6 specific mechanisms or if general
IPv6 mechanisms suffice. Are there other router -to- router
communications, for example?

In conclusion I would suggest this be discussed at the
IETF, preferrably after a draft update has addressed
some of the tradeoffs and alternative solutions above --
maybe in Vancouver if this can't be done before that.
(Assuming of course people on this list think that this
is an important enough problem to solve.)

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Jul 2005 13:18:17 -0700

jak>> Why not?

            jak

---

From: "Radhakrishnan.S" <[email-masked]>
Date: Fri, 15 Jul 2005 09:37:38 +0530

Hi Jari,
  I completely agree with your suggestion. Analysing and outlining different 
ways of solving the problem will really make this draft worth while. The 
authors should consider this aspect and take it to IETF for further 
discussion on the problem itself.

Regards
Radhakrishnan

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Jul 2005 08:47:39 +0300

>mandate SEND to be implemented and link to be secured
This reminds me of an argument that I often see in the IETF,
"implementations aren't doing RFC XXXX, so we have to develop
RFC YYYY to fix that". Needless to say, its often the case that
thereafter the implementations aren't doing either XXXX or
YYYY :-)

In some cases (perhaps with SEND too) one may wonder if
a complicated piece of other functionality is needed to implement
something simple. In such cases it may make some sense to
develop alternative schemes. However, in this particular case
it would suffice to implement a very small part of SEND, just the
RA security and only on the home agents, not on all nodes.
The scalability and ease of configuration of that part of SEND
is probably close to what any other cryptographic solution would
be able to offer, so working on other cryptographic solutions
would probably not make much sense. A non-cryptographic, liveness
based scheme might be OK, but they don't seem to address
the threat that people wanted to fix, so unless we invent something
new I don't think we want to go there.

Anyway, in this discussion I think we should first focus on
figuring out if a protocol mechanism is needed at all
rather than arguing what it should be. (A protocol mechanism
is not needed if, for instance, addition of some configuration
information to the implementations would avoid the need to
trust RAs. I'm not saying this solves this problem, but at least
we should look at it.)

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Jul 2005 08:37:24 -0700

> new I don't think we want to go there.

Yes, that's true.

Though the WG did have a discussion about whether or not to use IPsec on the
HA to MN connection, nobody seemed to be making the case that "we shouldn't
mandate using IPsec in Mobile IP" (though of course now we have the
mip6-auth option). I know protocol designers like to avoid "dependencies",
people are constantly trying to avoid using TCP and then they end up
reinventing congestion control.

My point was that if there is an existing protocol that solves the problem,
then why not use it?

> trust RAs. I'm not saying this solves this problem, but at least

Well it is always good to have a clear and concise statement of the problem
before attempting to solve it. If the problem lends itself to a
configuration solution rather than a protocol solution, then so much the
better.

            jak

---

From: Li Qin <[email-masked]>
Date: Tue, 19 Jul 2005 08:29:32 +0800

> the different home agents on the home link can be a problem.

Do you think that multiple home agents issue should be considered
recently in the working group?

-Qin