Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility

From: <[email-masked]>
Date: Mon, 28 Jun 2004 14:37:23 +0300

Hi Jean-Michel,

1) I agree that the issue that you mention is a
limitation. I'm not sure the security considerations
section is the right place to explain the limitation,
however; it seems that the limitation is functional
rather than security related.

In any case, Section 7.14 (Limitations) already
states: "Proxy Neighbor Discovery is not supported
by this specification." Do you think more text
is needed?

2) I believe there's a solution that can support
proxy ND with SEND; for now the WG has determined
that it will not include the solution in the current
RFC. However, there's a plan to develop an extension
later. I guess the interest level for SEND and its
combined use with things like MIPv6 determines how
soon is "later". Chairs?

3) In the meanwhile, MIPv6 home addresses and SEND would
work with so called virtual home networks where the
mobile nodes never go to. Care-of addresses will of
course work with SEND in any case.

--Jari

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Mon, 28 Jun 2004 14:58:06 +0200

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> Envoyé : lundi 28 juin 2004 13:37
> À : COMBES jean-michel FTRD/DTL
> Cc : [email-masked]
> Objet : Re: Problem of interaction between SEND(CGA) and the 
> IPv6 mobility
> 
> 
> 
> Hi Jean-Michel,
> 

IMO, this is a security issue because SEND works if the "proxy" has the
Mobile's key and so the issue is in fact linked to the CGA key distribution
(Mobile -> "proxy" or "proxy" -> Mobile)

> by this specification." Do you think more text

Yes, IMO, I think we need more text ... I am afraid to see in some drafts
"Just use SEND" as we saw for RFC 2401 with "Just use IPsec".

> mobile nodes never go to.

Agree. This is the right solution for MIPv6, HMIPv6 and NEMO ...

> Care-of addresses will of

... but with FMIPv6 we have still a problem: the "proxy" function is
concerning the Co@ (for the tunneling between the PAR and the NAR).

> --Jari

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

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Mon, 28 Jun 2004 15:02:32 +0200

> > section is the right place to explain the limitation, however; it 
> > seems that the limitation is functional rather than 
> security related.
> 
> IMO, this is a security issue because SEND works if the 
> "proxy" has the Mobile's key and so the issue is in fact 
> linked to the CGA key distribution (Mobile -> "proxy" or 
> "proxy" -> Mobile)
> 
> > 
> Yes, IMO, I think we need more text ... I am afraid to see in 
> some drafts "Just use SEND" as we saw for RFC 2401 with "Just 
> use IPsec".

Sorry, I meant RFC 2461 ...

---

From: Greg Daley <[email-masked]>
Date: Wed, 30 Jun 2004 13:14:58 +1000

Hi Jean-Michel,

> "Just use SEND" as we saw for RFC 2401 with "Just use IPsec".

I think that 'Just Use SEND' is probably better
in some cases, because it has fallback modes for
non-signed messages.

There are other issues than whether the messages are
signed or not which affect mobile IPv6.

> Agree. This is the right solution for MIPv6, HMIPv6 and NEMO ...

I always through it was, regardless of whether SEND is in use...

> concerning the Co@ (for the tunneling between the PAR and the NAR).

Indeed.

There is almost always going to be a problem
in MIPv6 for existing Mobile Nodes which move off a home
network and peers still have a valid neighbour cache
entry.  A Home agent won't be able to override NC entries with
proxy advertisements if the override flag is unset in NAs.

This isn't a direct problem with SEND though, since existing
ND has this issue too.

Of course, I've not waded through RFC3775 recently to
see how proxy neighbour discovery is handled in this case
(maybe Jari knows better).

If the peer is a SEND node though, the poblem is complicated,
since it may have knowledge of the other device's previously
used keying material even if the NCE isn't in a valid state.
This may make an unsecured NA get ignored.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Jun 2004 15:47:24 -0700

> (maybe Jari knows better).

as soon as a binding cache is created, the Home Agent sends a
gratuitous proxy neighbor advertisement. since this advertisement
is not solicited, the Override flag is set to 1.

even for solicited proxy neighbor advertisement, the RFC 3775
says Override flag MUST be set. (section 10.4.1)

Vijay

---

From: Greg Daley <[email-masked]>
Date: Thu, 01 Jul 2004 13:50:59 +1000

Hi Vijay,

> says Override flag MUST be set. (section 10.4.1)

See what I could have learnt if I'd actually
read the spec...

I guess this is relying on 7.2.8 of 2461 too.
(so there never really was a problem... sorry).

It's not really very reliable in terms of SEND though
(even if there was an authorization mechanism which allowed
this), where unsolicited messages are matched with
timestamps based on the advertisor's perception of time.

The sudden change of advertisor could certainly
cause headaches if this wasn't managed (or worked around),
as otherwise the new advertisor's message could fall outside
the fuzz and drift allowances.

What I'd like to see would be some sort of authorization
which could be signed by the address owner, which could be overridden
by a later one (like a last will and testament) signed and timestamped
by the same owner.
This would authorize SEND nodes to receive a proxied solicited NA
as an override, although they would defer to the original
address owner if it returned to the link.
(the O=0 flag would still be set for non-SEND nodes, to preserve
existing function).

I'd guess this could all be based on the owner's perception of
time, although there may be problems if that changes suddenly.

Certainly providing the router with authority to do this may
be problematic when a device isn't on the link.

In the MIPv6 case, it may be possible to exchange delegation
chain messages over the home tunnel to ensure that the MN knows
that the HA is authorized to be a router for the prefix.
Also, the MN could sign the key of the router and send back
a proxy certificate by a similar message.

There may have to be a control plane request in the message
sent back to the router which could request use of the address,
and proxying.  With MIPv6 this is already done if the
proxy certificate is sent within a BU/BAck.

Greg