Subject: RE: [nemo] MR definition

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Dec 2002 09:55:40 -0000

>> MIPv6 support by all routers should be present on all ingress interfaces, correct?
> 
> I do not understand what you mean?  Not all routers will need
> to support NEMO, only the mobile routers and the HAs, right?

Sorry for being unclear. I meant requirements 8.1 (easy) and 8.3 page 62 in MIPv6 draft 19 should be part of Nemo basic support for MRs on all ingress interfaces. 

The MIPv6 support on egress interface is the tricky thing that we'll have to define. I guess basic support does not need RO as a MN or CN at all, does it? The way I see it, we'd need a subset of 8.5, excluding the RR procedure, and we should not need section 9.

What do you think?

Pascal

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: vendredi 13 décembre 2002 09:50
> To: Pascal Thubert (pthubert)
> Cc: Pekka Pääkkönen; [email-masked]
> Subject: Re: [nemo] MR definition
> 
> 
> "Pascal Thubert (pthubert)" <[email-masked]> writes:
> > Is that fair from all this discussion to consider that for basic
> > support, Pekka's summary is correct? For one, this seems to 
> work fine,
> > and second this saves a lot of text in basic support doc by simple
> > inheritence from knell-known models.
> 
> YEs, I see PEkka's summary as correct and good paragraph beginning.
> 
> > Still for basic support, I suppose we need to extend Pekka for some
> > MIPv6 support as well. On the egress interface the basic 
> support for
> > Nemo would include Mobile Node (RO and CN excluded). And
> MIPv6 support
> > by all routers should be present on all ingress interfaces, correct?
> 
> I do not understand what you mean?  Not all routers will need
> to support NEMO, only the mobile routers and the HAs, right?
> 
> Alex
> 
>

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Dec 2002 12:58:19 +0100

"Pascal Thubert (pthubert)" <[email-masked]> writes:
> Sorry for being unclear. I meant requirements 8.1 (easy) and 8.3
> page 62 in MIPv6 draft 19 should be part of Nemo basic support for
> MRs on all ingress interfaces.

Ah yes, I see.  Let me give it a try at fitting Mobile IP HA
requirements with NEMO HA requirements.

From draft-mobileip:
  "8.1. All IPv6 Nodes

   Any IPv6 node may at any time be a correspondent node of a mobile
   node, either sending a packet to a mobile node or receiving a packet
   from a mobile node.  There are no Mobile IPv6 specific requirements
   for such nodes, and standard IPv6 techniques are sufficient."

Is indeed easy, it's same for MR, as you say.

    "-  Every home agent MUST be able to maintain an entry in its Binding
        Cache for each mobile node for which it is serving as the home
        agent (Sections 10.1 and 10.3.1)."

Same.

    "-  Every home agent MUST be able to intercept packets (using
        proxy Neighbor Discovery [12]) addressed to a mobile node for
        which it is currently serving as the home agent, on that mobile
        node's home link, while the mobile node is away from home
        (Section 10.4.1)."

Same.

    "-  Every home agent MUST be able to encapsulate [15] such
        intercepted packets in order to tunnel them to the primary
        care-of address for the mobile node indicated in its binding in
        the home agent's Binding Cache (Section 10.4.2)."

Same.

    "-  Every home agent MUST support decapsulating [15] reverse tunneled
        packets sent to it from a mobile node's home address.  Every home
        agent MUST also check that the source address in the tunneled
        packets corresponds to the currently registered location of the
        mobile node (Section 10.4.3)."

In the MR case, the src address of the encapsulated packet is not MR's
CoA, but it is the fixed address of an LFN or the address of a
visiting MH that derives its CoA from the MNP.  This is probably a
security threat.

    "-  The node MUST be able to process Mobility Headers as described in
        Section 10.2."

Same.

    "-  Every home agent MUST be able to return a Binding Acknowledgement
        in response to a Binding Update (Section 10.3.1)."

Same.

    "-  Every home agent MUST maintain a separate Home Agents List for
        each link on which it is serving as a home agent, as described in
        Sections 10.1 and 10.5.1."

Same.

    "-  Every home agent MUST be able to accept packets addressed to
        the Mobile IPv6 Home-Agents anycast address for the subnet
        on which it is serving as a home agent [16], and MUST be
        able to participate in dynamic home agent address discovery
        (Section 10.5)."

Same.

    "-  Every home agent SHOULD support a configuration mechanism to
        allow a system administrator to manually set the value to be sent
        by this home agent in the Home Agent Preference field of the Home
        Agent Information Option in Router Advertisements that it sends
        (Section 7.4)."

Same.

    "-  Every home agent SHOULD support sending ICMP Mobile Prefix
        Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
        Solicitations (Section 6.7).  This behavior MUST be configurable,
        so that home agents can be configured to avoid sending such
        Prefix Advertisements according to the needs of the network
        administration in the home domain."

In the NEMO case, this SHOULD could be a MAY.  MR will probably not
need Mobile Prefix Advertisements from its home link.  We were saying
previously that MR will probably not need to receive RAs from the home
link, so neither will it need Mobile Prefix Advertisements.

    "-  Every home agent MUST support IPsec ESP for protection of packets
        belonging to the return routability procedure (Section
        10.4.4)."

Depends on RO issues in NEMO.

In addition to the above requirements, if MRTP with MRHA uses dynamic
routing protocols between MR and HA then "HA MUST subscribe to the
all-routers mc address with link scope".

What do you think?

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 13 Dec 2002 13:34:37 +0100

> visiting MH that derives its CoA from the MNP.  This is probably a

I don't know what you mean.

I think the I-D talks about the source address of the outer packet. It
should be equal to the current CoA of MR. Nothing new.

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Dec 2002 13:54:21 +0100

> should be equal to the current CoA of MR. Nothing new.

I don't know what they mean.  

I thought that they wanted that, in the MH case (MH: mobile host), the
HA checks the source address of the packet that is tunnelled (inner
packet's src) and ensure that that src address equals the home address
corresponding to the CoA that is registered in the binding cache.
That's how I interpreted the above paragraph.  If that interpretation
is correct, and in the MR case, then that check would fail because the
inner packet's src address does not equal the outer packet's CoA in
the binding cache entry.  Thus there would be a need for HA to act
differently for MRs than for MHs.  And if that check was considered to
be useful for MH to prevent security attacks, and we eliminate that
check in NEMO, we validate the security attacks.

Of course, if my interpretation of the MIPv6 paragraph is wrong, and
the HA only checks for the src address of the received outer packet,
then that src address is indeed MR's CoA, and then indeed there's
nothing new for NEMO.  The only suggestion would be to change to

 - Every home agent MUST support decapsulating [15] reverse tunneled
   packets sent to it from a mobile node's home address.  Every home
   agent MUST also check that the source address in the outer header
   corresponds to the currently registered location of the mobile node
   (Section 10.4.3).

Note change "the source address in the tunneled packets" to 
            "the source address in the outer header"

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 13 Dec 2002 14:09:54 +0100

> check in NEMO, we validate the security attacks.

Ok, I can see your concern. I don't know if such a thing has ever been
discussed in Mobile IP, although it may be a very reasonable thing to
do.

In general, checking the source address of packets would certainly help
for various reasons.

Maybe we can add a recommendation that a Home Agent supporting NEMOs
should perform ingress filtering, so that only topologically correct
packets leave the HA.

>             "the source address in the outer header"

Sounds better.

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Dec 2002 14:40:10 +0100

> discussed in Mobile IP, although it may be a very reasonable thing to

I don't know either, might very well be that IPsec protects everything
between MH and HA (sorry for using MH instead of MN) and thus no need
of these kinds of "functional" checks.

> In general, checking the source address of packets would certainly
> help for various reasons.

Yes.

> should perform ingress filtering, so that only topologically correct

Could you be more explicit?  Do you mean that LFN sends packet to CN:
goes to MR that encapsulates towards HA that decapsulates and, before
sending, checks to see the source of that outgoing packet is correct?
Or something else?

What is ingress filtering at the HA?

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 13 Dec 2002 15:00:50 +0100

> sending, checks to see the source of that outgoing packet is correct?

Sorry for being unclear. But I meant exactly what you describe.

HA should verify that packets it receives from the MRHA tunnel have a
source address that matches what's in HA's routing table. HA should have
a route for the mobile prefix pointing into the MRHA tunnel, and the LFN
should have use a source address derived from that prefix when sending
its packets. Other packets will be dropped.

> What is ingress filtering at the HA?

What you described.

/Mattias

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 17 Dec 2002 12:02:36 -0800

Alexandru Petrescu wrote:

> visiting MH that derives its CoA from the MNP.  This is probably a

MIPv6 meant check the source address on the outer header. compare 
it with the CoA in the binding cache entry for the corresponding 
home address. this is to prevent a node from tunneling traffic 
through the home agent, if it is not registered with the home agent 
currently. this is similar to ingress filtering that a router would 
do when it forwards packets.

For the MR case, the HA needs to do this check, but the check is 
slightly different. it has to make sure the source address in the 
inner header belongs to the MR's prefix. and the source address in 
the outer header needs to match the current CoA of the MR.

> link, so neither will it need Mobile Prefix Advertisements.

agreed.

> all-routers mc address with link scope".

HA is a router. it would have joined the all-routers multicast 
address anyway.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 18 Dec 2002 11:52:14 +0100

> the outer header needs to match the current CoA of the MR.

Yes, right.  When nested mobility, and several HAs, then a HA will
receive packets from an MR that have several headers inside.  Thus,
talking about inner and outer header should be talking about addresses
in "outermost"(?) header and "next to outermost"(?) header?

I mean, the HA will only check src and dst addresses only in the
outermost and next to outermost headers, but not the addresses in
deeper headers, right?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Dec 2002 10:42:28 -0800

> outermost and next to outermost headers, but not the addresses in

it is simple. each HA has to check the source addresses of outer 
and inner IPv6 headers of the packet it decapsulates and forwards. 
it doesnt matter how many times the packet has been encapsulated.

why check the destination address? the destination address on the
outer header is going to the HA and on the inner header some random
CN.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 18 Dec 2002 20:06:35 +0100

> it doesnt matter how many times the packet has been encapsulated.

I see, so let's have a path of HAs like this:

HA1--HA2--HA3--HA4

And the packet is decapsulated progressively by HA1, 2 and only at HA4
is it totally decapsulated and has no outer header at all.

HA1 receives a packet with 4 headers inside.  It "checks src in outer
header" ok.  Then it checks src in inner header, but there are 3 inner
headers, so which one to check.  Maybe, the first inner header?  The
second inner header?

If HA1 only checks the first inner header, then it is possible for an
attacker deep in the mobile network hierarchy to put a fake source
address that will only be discarded at HA4 when HA4 checks the source
address and drops it.  Thus the attacker generated network load on the
path HA1-HA2...4

Did I miss anything in unfolding my scenario?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Dec 2002 12:57:15 -0800

> If HA1 only checks the first inner header, then it is possible for an

only the first inner header.

> Did I miss anything in unfolding my scenario?

yes. a HA cannot always look beyond the first inner header. it could
be encrypted by a tunnel ESP SA between the corresponding MR and HA.
for example lets assume the following.

MR3 is nested under MR2 which is nested under MR1. also assume HA1 
is serving MR1, HA2 is serving MR2 and HA3 is serving MR3. the
packet could look like the following.

IPv6 hdr (MR1_CoA, HA1)
IPv6 hdr (MR2_CoA, HA2)
IPv6 hdr (MR3_CoA, HA3)
IPv6 hdr (x, CN)                (x is a node in MR3's network).
Payload

now further assume MR2 and HA2 use an ESP encrypted tunnel. that
means when HA1 receives a packet which looks like the following.

IPv6 hdr (MR1_CoA, HA1)
IPv6 hdr (MR2_CoA, HA2)
ESP hdr... encrypted payload.

HA1 MUST verify MR1_CoA is valid by looking at the binding cache 
entry for MR1. it SHOULD also verify that MR2_CoA belongs to 
MR1's mobile network. it shouldnt care if MR2_CoA is a mobile 
router. infact it shouldnt care what IPv6 headers follow. it
should be concerned only about the packet it is decapsulating
and forwarding.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 21 Dec 2002 02:40:58 +0100

> for example lets assume the following.

Ah yes, thanks for the example with ESP.

It is very true that HA can not look deeper at packet headers if ESP
is used.  But if ESP is not used, then it could, right? (it is not
clear to me whether Mobile IPv6 requires that MN MUST use ESP to HA
for signalling only, or for all communication to HA?  Do you know?)

So, maybe the HA could be instructed to look at all packet headers as
deep as it could (as long as it doesn't encounter an ESP header), and
do checks on addresses.

To me, the unknown is what kinds of checks could be done on addresses
that are deep in the tunnel headers, and that are in no relation to
the addresses known by this HA.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Dec 2002 10:11:12 -0800

> for signalling only, or for all communication to HA?  Do you know?)

no. Mobile IPv6 requires ESP tunnel only for RR signaling. but, 
at any time any MR could setup an ESP tunnel instead of an 
unprotected tunnel between its home agent and itself. it could 
use the ESP tunnel for all traffic. 

the tunnel could also be a VPN tunnel between the MR (in the 
foreign link) and its HA back in its corporate network. the VPN 
case (IMO) might be very common.

> deep as it could (as long as it doesn't encounter an ESP header), and

no. a HA has no business looking beyond the IPv6 header of the packet
it decapsulates and forwards.

> the addresses known by this HA.

these addresses are not related to this HA. so it cant do any checks
even if it wants to. it should leave it to the corresponding HA.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 31 Dec 2002 08:57:35 +0100

> case (IMO) might be very common.

IMO there's an important difference between a VPN Gateway and a HA.
The VPN Gateway is usually one per company, while there can be as many
HAs as there are IP subnets in that company.

If VPN Gateway is used then there are potentially 2 tunnels even if we
only talk mobile hosts (not routers).  One tunnel between MN and VPN
GW and another tunnel, through the first, between MN and its HA.

> even if it wants to. it should leave it to the corresponding HA.

Every MR will generate encapsulated packets of the form:
MR_CoA (this MR's CoA)
MR_HA (the address of the HA of this MR)
------
LFN_source (the address of the LFN behind MR)
dest

The LFN_source and MR_HA addresses should have a common prefix,
usually.  This could be checked by any HA.

Of course, there could be deployments where the mobile network's
prefix is totally different than the prefix of the fixed home network.
I see these as exceptions.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Dec 2002 10:38:15 -0800

> HAs as there are IP subnets in that company.

we could get into an endless argument here about where a VPN
gateway and HA are placed in a network. but what you say below
is not true.

> GW and another tunnel, through the first, between MN and its HA.

see section 7.2.4 of
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-01.txt.
just change 'proto = X' to 'proto = any' in mobile node SPD OUT 
entry. this basically becomes your IPsec VPN tunnel encrypting 
all traffic reverse tunneled between the MN and the HA. you can
do with just one tunnel in this case.

> MR_HA (the address of the HA of this MR)

what is -----?

> usually.  This could be checked by any HA.

ofcouse I agree with that. I kept saying each HA checks only
the outer and inner IPv6 headers of the packets it decapsulate
and forwards.

if the packet is as follows,

MR_CoA
MR_HA
LFN_source
CN

then the HA has to make sure LFN_source belongs to the HA prefix.
but if the packet looks as follows

MR1_CoA
MR1_HA1
MR2_CoA
MR2_HA2
LFN_source
CN

then HA1 checks if MR2_CoA belongs to the HA1 prefix. but does not
look beyond that header. it doesnt care what headers follow. HA2 
checks if LFN_source belongs to HA2's prefix.

> I see these as exceptions.

I was not talking about that at all.

Vijay

ps: maybe we can take it offline....

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 31 Dec 2002 20:51:08 +0100

Vijay Devarapalli wrote:
> gateway and HA are placed in a network.

Yes... :-)

> do with just one tunnel in this case.

I'll look at that description Vijay.

>>MR_HA (the address of the HA of this MR)

Separator, fine line :-)

> checks if LFN_source belongs to HA2's prefix.

It's not that HA1 couldn't check for this.

Ok, maybe we can move this offline.

Alex