Subject: Re: [nemo] Question on MR - CN

From: Thierry Ernst <[email-masked]>
Date: Fri, 7 May 2004 15:03:31 +0900

Hi,

For security reasons, we decided to use a bidirectional tunnel, so
encapsulation between MR and HA in both directions. This was decided
before the actual set up of the NEMO WG. I don't know if there is a
particular thread to recommend you, but probably that would be on the
monet ML archives, not the nemo ML archives. 

Thierry.

On Wed, 28 Apr 2004 09:59:53 +0800
Benjamin Koh Tien-Ming <[email-masked]> wrote:

> Hi!
> 
> I have a question on MR operation that I'm hoping someone can help clarify.
> 
> In the case when the MR is away from home, a LFN sends a packet to a CN. 
>   Can the MR encapsulate the original packet and forward it directly to 
> the CN using it's current CoA (Care-of-Address)? Are there any reasons 
> against or problems with using such a method?
> 
> Please direct me to a relevant thread if this question had been 
> previously raised.
> 
> Thanks!
> 
> Regards,
> Benjamin
> 
>

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 7 May 2004 15:03:31 +0900

Hi,

Thierry.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sat, 08 May 2004 19:34:15 -0700

>monet ML archives, not the nemo ML archives. 
I looked through my monet archives and didn't come up with much on this 
subject. Most of the discussion happened between authors of 
requirements/solution specs at the time. The first thread I find with a 
quick search is from a year ago:

On May 27, 2003, Greg Daley wrote:

> Routers in the visited fixed network will Ingress filter
> to prevent address spoofing.
> Reverse tunnels are required, so that MNNs have an
> address on the NEMO which is topologically correct.
>
> Greg Daley.
>
> atq atiq wrote:
>
>> Dear all,
>> As a new customer, i don't understand the need for tunnelling for the
>> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> HAofMR ---> CN
>>
>> to send packets from VMN to CN [assume that CN already sent some to
>> VMN].
>>
>> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR,
>> what is the prob. or otherwise what's the benefits?
>>
>> Pls. let me know.
>>
>> Thanks in advance.
>>
>>
>> aa
>>
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
>> http://calendar.yahoo.com
>

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sat, 08 May 2004 19:34:15 -0700

---

From: Chan-Wah NG <[email-masked]>
Date: Sun, 09 May 2004 11:26:38 +0800

This is interesting, there is no concrete explanation on what the
"security threats" are.  I guess most of us just assumed that direct
tunneling to CN is "somehow insecure", at least I do, without giving it
serious thought.

According to the "Generic IPv6 Tunneling" RFC 2473, a tunnel exit node
should just discard the outer packet and process the inner packet as
though it has been delivered through a network interface.

Perhaps we should ask what is the "security threat" here?  The ingress
filtering problem shouldn't be a concern, since we would assume the
outer packet bears the CoA of MR as the src.

The only issue I can think of is, not related to security, is the CN is
implemented not to accept tunnel from any nodes.  For that, I consulted
the IPv6 Node (or Host) requirements draft, but there was no mention on
tunnel handling requirement.

Any thoughts on this from others?

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Sun, 09 May 2004 11:26:38 +0800

/rgds
/cwng

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 10 May 2004 13:39:30 +0200

Hi,

I have also been wondering about this issue for a while now.

RFC 2003, states that a host should accept encapsulated packets if both
inner and outer addresses belong to the host.

However, MIPv6, states that a HoA option cannot be processed if a valid
(authenticated) BCE exists in the host.

Moreover, the transition mechanisms IPv4-IPv6 state that the only
encapsutaled packets that are accepted are those thay belong to exsiting
tunnels, toher shoudl be discarded.

Finaly, 6to4 accepts all encapsulated packet, and a threats document is
being discussed in v6ops.

I guess that the main risk that this introduces is that source address
spoofing is much more simpler thant today. I also guess that current
implementations don't really accept encapsulated packets by defualt.

So, in brief, older specs state that encpasulated packets may be accepted
but newer ones are moving from that and only packets belonging to existent
tunnels are accepted.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En nombre de
> Chan-Wah NG
> Enviado el: domingo, 09 de mayo de 2004 5:27
> Para: IETF NEMO WG
> Asunto: Re: [nemo] Question on MR - CN
>
>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 10 May 2004 13:39:30 +0200

Hi,

Regards, marcelo