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

From: Soliman Hesham <[email-masked]>
Date: Tue, 18 Nov 2003 09:31:15 -0500

> Just for reference, I think the discussion at the session
 > was that P and I bits were useful only if ingress filtering was
 > not applied to communications using the MAP prefix, within a domain.

=> Obviously I wasn't there, but, as specified in the draft,
those flags are needed to communicate three different issues:

1. The MN MUST use RCoA as a src address (this is because the 
operator doesn't want to show its internal addresses). 

2. The MN MAY use RCoA as a src address if it wishes to 
get location privacy. 

3. If for any reason the MN uses RCoA as a src address, 
it MUST tunnel all outgoing packets to the MAP (when the 
V flag is set).

 > 
 > It was difficult to see how this could be maintained on the edge of
 > a MAP domain, where it was possible that an MN roamed into a new
 > access network but needed (temporarily) to send and receive packets
 > using the existing RCoA.  Considering that the host may not know
 > (with current map options) whether it is in the same domain, and if
 > the RCoA can be used as a source without tunnelling.

=> But how can the host send or receive anything in the 
new domain if it hasn't received an RA to configure an
appropriate address? If it did, it would know what to
do, if it didn't then it can't send anything anyway. 
Am I missing something? 

 > There are several reasons why  Dynamic propagation of information
 > is better than static configurations such as may be available in
 > DHC or in a router configured using command line options or
 > RADIUS.

=> Agreed.

 > 
 > The principle ones are that network topology can change, or
 > that the status of the HMIPv6 MAP is not actually known by
 > an advertiser.  Therefore, it would make sense if advertisement
 > was taking place, to develop a mechanism which allows dynamic
 > advertisement of HMIPv6 MAPs (or MIPv6 HAs), which actually
 > reflect the status of these systems.

=> I'm not sure I understand the problem with the Dynamic MAP
discovery, but there is a simple way to make it transparent
to intermediate routers: Develop a new ICMP message that goes
from the MAP to all ARs in its domain. This will make 
the discovery dynamic and it won't require intermediate
routers to propagate the MAP option (if that's the problem).

 > 
 > How to do this correctly sounds like IRTF work.

=> Yes, possibly.

Hesham

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

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 18 Nov 2003 16:00:50 +0100

Hi Hesham,

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]De la part de
> Soliman Hesham
> Envoyé : mardi 18 novembre 2003 15:31
> À : [email-masked]'; gabriel montenegro
> Cc : [email-masked]
> Objet : RE: [Mipshop] Last Call Comments on
> draft-ietf-mishop-hmipv6-00.txt
>
>
>

[snip]

> routers to propagate the MAP option (if that's the problem).

BTW, just a comment : I think that some text should be added in the
'Security considerations' section, regarding how to secure the signalling of
such a mechanism (ie. ICMP message that goes from MAP to all ARs).

[snip]

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Nov 2003 10:19:00 -0800

> it MUST tunnel all outgoing packets to the MAP (when the

Ah, now I understand what you meant about location privacy.

Suppose the MN reverse tunnels to the MAP, with the outer packet having the
LCoA as the source, and the inner packet having the RCoA as the source. This
would achieve the same effect without the possibility of compromising
ingress filtering. This exposes the LCoA to eavesdroppers within the
administrative domain, however, the problem is no worse than with standard
MIPv6 in that regard between the HA and MH.

If the MN has done route optimization using the RCoA with the CN, there
should be not be a problem with double tunnel overhead, though on the
initial contact through the HA there might be if RO is not done immediately.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 19 Nov 2003 10:20:39 +1100

Hi Hesham,

> it MUST tunnel all outgoing packets to the MAP (when the 

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?

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?

> do, if it didn't then it can't send anything anyway. 

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.

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

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.

There's little to stop this in the current draft, but
packet loss due to ingress filtering may occur if P or I
are set, and packets are going out with a source address
where they're not explicitly under MAP coverage.

> routers to propagate the MAP option (if that's the problem).

It may be worthwhile to have a multicast group for that,
but I think key distribution is likely to be an issue.

If we're talking about changes to routers, it may be worthwhile
to make a change to a routing protocol like OSPF to put a
"Routing proxy" LSA into it.

We're actually talking about a routing change, so advertisement
of MAP options could be tied to reception of routing proxy updates.

This could use existing security mechanisms for routing.

I'd guess that the number of routing proxy LSA's advertised would
be quite low, but the status of the MAP's advertisements would be
tied to SPF routing.

This may be a pretty far out idea, considering that the MAP
looks like a server in the network.

>  > How to do this correctly sounds like IRTF work.

Greg

---

From: Greg Daley <[email-masked]>
Date: Wed, 19 Nov 2003 13:49:41 +1100

Hi James,

> MIPv6 in that regard between the HA and MH.

If packets are encrypted between the MN-HA and MN-MAP then there's no
way (except through correlating packets received from the MN with
those decapsulated and sent by the MAP) to determine the location
of the MN within the access network.

There's some information available through RTT measurement,
but that only reveals propagation from the MN<->HA or MN<->MAP,
not the on-link CoA.

> initial contact through the HA there might be if RO is not done immediately.

Transient MTU issues are likely to be a problem in FMIPv6
as well as HMIPv6, if the fixed network has the same MTU
as the wireless (for example, I think Ethernet has a lower
MTU than WLAN).

It's definitely worth seeing if this is a big problem.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Nov 2003 08:41:49 -0800

Greg,

Comments

> of the MN within the access network.

If the MN is tunneling to the MAP, then the addresses in an outbound packet
header look like this:

    outer destination address: MAP address (probably RCoA)
    outer source address: LCoA
    inner destination address: CN address (or HA address if no route
optimization)
    inner source address: RCoA

Suppose there's an eavesdropper on the link between the MAP and the MN. Even
if there's an IPsec ESP tunnel header between the outer and inner packets,
the eavesdropper will be able to read the LCoA in the outer header and track
the mobile's movement, if it has a map of where which subnet prefixes
correspond to which geographical regions.

Furthermore, BUs are sent in the clear and an eavesdropper could track
movement through BUs, though there are fewer of them, so the eavesdropper
would need to be more persistent to catch them. But that's a separate
problem, since it would occur for both tunneled and non-tunneled traffic.

> as the wireless (for example, I think Ethernet has a lower

MTU with multiple tunnels is an issue.

            jak