Subject: RE: [Mipshop] Last Call Comments on draft-ietf-mishop-hmipv6-00.t xt

From: Soliman Hesham <[email-masked]>
Date: Wed, 19 Nov 2003 00:34:06 -0500

Hi Greg, 

 > In order to achieve MIPv6 route optimization though,
 > it is necessary to reverse-tunnel packets to the MAP
 > (the CoT/I messages).
 > 
 > Is it necessary to have a P and an I bit, if we already
 > have a mechanism to achieve location privacy using reverse
 > tunneling?

=> It's always the case that we use reverse tunnelling, 
the I flag is there to tell the MN that it can do that. 

 > 
 > What I'm asking is: whether you think it buys much to have
 > the RCoA as source address on packets given the difficulty
 > in determining whether the packets with this source address
 > will pass ingress filtering?

=> I really don't care for having a flag that tells the 
MN that it MUST use its RCoA as a src because the operator
wants to hide its addresses. But as I said earlier, others
asked for this feature. 

However, I think it's useful to have a flag that
tells the MN that location privacy is available through
reverse tunnelling or directly sending packets with RCoA
as a src. 

 > OK, so then we should discard the binding to the old MAP,
 > on receiving an RA without the MAP option, if P or I is set.

=> No, the I flag has nothing to do with this. You
can always reverse tunnel to the old MAP provided 
that you sent a new BU to provide the new LCoA. 

 > I guess that the issue arises because of the instruction
 > to be "Lazy" in releasing existing bindings.

=> See above, I still don't see where the problem 
is.

 > At least until the BU to the new MAP occurs (and return
 > routability tests to CNs have completed) it's valuable
 > to maintain both connections to MAPs.

=> This is possible, operators just have to configure
their routers accordingly.

Hesham

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

---

From: Greg Daley <[email-masked]>
Date: Wed, 19 Nov 2003 17:06:38 +1100

Hi Hesham,

> the I flag is there to tell the MN that it can do that. 

Actually, the I flag only indicates that the RCoA may be used
as a source address.  It doesn't indicate reverse tunneling at all.

The V flag indicates that tunneling may be used (must be used
for packets sent with RCoA source when P or I is set)

Here's the text:
(Section 5)
"  I        When set indicates that the mobile node MAY
             use its RCoA as source address of its outgoing
             packets"

the last section of section 6.1 has more detail on the
relationship between these flags:

"... Hence, the mobile node should use its RCoA as a source address
    for all its outgoing packets. This can be done if the I or P flags
    are set in the MAP option. Otherwise location privacy can not be
    provided in this manner.

    If the V flag is set (in addition to the P or I flags), the mobile
    node MUST tunnel all outgoing packets to the MAP. This is needed to
    allow for location privacy while keeping ingress filter configuration
    in the ARs unchanged.
"

in section 6.1.1, communications to the CN are mentioned:

"Since RCoA is used as a source address for outgoing packets, the
    mobile node must consider the content of the P, I and V flags to
    decide whether packets should be sent directly with RCoA as a source,
    or tunnel packets to the MAP. When tunnelling outgoing packets to the
    MAP, the source address in the outer header is the mobile nodeËs LCoA
    and the destination address is the MAPs address. "

What the actual intention is and what the specification
is seem to be out-of-sync.
Certainly, it's not necessary to have all three of I, P and V.

V=1 is assumed as default.

P and I seem to be way of indicating alternatives to reverse
tunneling (but I'm not sure why any more).

> wants to hide its addresses. But as I said earlier, others

I'd guess that was before reverse tunneling was commonplace
though.

> reverse tunnelling or directly sending packets with RCoA

Isn't location privacy always available (through reverse tunneling)?

> their routers accordingly.

The issue is that a MAP may only be applicable to one operator,
and using the MAP during handover to another operator's MAP
will lose packets (since the new operator will drop packets
with the old RCoA as a source address).

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Nov 2003 13:30:27 -0800

Greg/Hesham/Gab,

Basically, my take on this is that the RCoA and reverse tunneling should
always be used, and the MN should always reverse tunnel to the MAP, and the
access router should always maintain ingress filtering for the local subnet.
This gives location privacy outside the administrative domain, but not if an
eavesdropper compromises the network inside. I believe this is preferable to
opening up the ingress filter (note that this problem has been removed from
FMIP since the MN's nCoA will be used for the tunnel endpoint) because the
liklihood of compromise within the network is relatively low relative to the
liklihood that someone could misuse an open ingress filter to send spam or
something like that.

If the MN is in the same domain, the MN could not route through the MAP if
it wants optimized routes but rather could use RO directly immediately after
the CN contacts it (or vice versa) through the HA. Just how the MN
determines that the CN is in the same administrative domain is another
question. Also, the MN has no location privacy but it doesn't have to use
RO, it could route through the MAP.

So, I think the I, P, and V flags should all be removed. In other words, I
agree with Gab.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Soliman Hesham" <[email-masked]>
Cc: "gabriel montenegro" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 18, 2003 10:06 PM
Subject: Re: [Mipshop] Last Call Comments on draft-ietf-mishop-hmipv6-00.t
xt

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Thu, 20 Nov 2003 18:17:26 +0100

Hi James,

what do you really mean by location privacy inside the administrative domain
?
Do you mean that an eavesdropper may follow MN's movements ?
If so, for the BU, why not just use RFC 3041 address for the outer source
address with LCo@ in the Alt-Co@ plus IPsec/ESP(encryption) and during
communications between MN and CN (without RO, ie. reverse tunneling), use
LCo@ for the outer source address and RCo@ for the inner source address plus
IPsec/ESP(encryption) ? And if the eavesdropper uses the 64 latest bits of
the MN's address to follow the MN (eg. case where the eavesdropper is always
on the path between MN and HA), why not use RFC 3041 all the time for the
LCo@ ?

Am I wrong ?

Regards.

JMC.

France Telecom R&D - DTL/SSR
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

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]De la part de
> James Kempf
> Envoyé : mercredi 19 novembre 2003 22:30
> À : [email-masked]; Soliman Hesham
> Cc : gabriel montenegro; [email-masked]
> Objet : Re: [Mipshop] Last Call Comments on
> draft-ietf-mishop-hmipv6-00.t xt
>
>
> Greg/Hesham/Gab,
>

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Thu, 20 Nov 2003 18:21:27 +0100

Hi again,

> COMBES jean-michel FTRD/DTL
> Envoyé : jeudi 20 novembre 2003 18:17
> À : James Kempf; [email-masked]; Soliman Hesham
> Objet : RE: [Mipshop] Last Call Comments on

I mean on the path between MN and MAP ... sorry.

Regards.

JMC.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Nov 2003 10:07:30 -0800

> Do you mean that an eavesdropper may follow MN's movements ?

Yes.

> on the path between MN and HA), why not use RFC 3041 all the time for the

The subnet prefix of the CoA always provides information on the geographic
location of the mobile regardless of whether RFC 3041 addresses are used.
RFC 3041 addresses disrupt the ability to correlate flows as originating
from the same host, but they don't entirely mask the host's identity. Since
I believe (and please correct me if I am wrong) the Home Adress Option is
always sent outside ESP, the BU to the HA will provide the correlation
between the host's fixed identity and the RCoA, and, from the BU to the MAP,
the LCoA. At that point, the attacker can infer the geographic location from
the LCoA's subnet prefix.

Of course, YMMV. The above requires the eavesdropper to monitor a lot of
infrequently sent traffic which makes the problem more difficult. Also, the
size of the access network subnets controls how useful the geographic
information is for an attacker even if they manage to figure it out. Subnets
spanning larger geographical regions mean the attacker (should they want to
actually find and physically harm the victim) must control more resources.

            jak

PS: There are other solutions to location privacy that are more secure but
don't involve using Mobile IP. Unfortunately, they all have significant
disadvantages in various ways.