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

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 10 May 2004 08:25:39 -0400

Hi, 

I found it difficult to understand the original question.
But tunnelling to the HA was included in the charter
as a working assumption. At the time this was the best
wording we could come up with to satisfy IESG, IAB...etc
without explicitly naming the solution. 

Tunnelling to the CN has the same security problems
as the HAO. RO in MIPv6 is essentially the same as tunnelling.

The reason tunnelling to any random CN is not being suggested
is that no implementation today accepts an unauthorised tunnel. 
Of course the reason is reflection attacks. 

So unless the tunnel is secure (which is effectively what 
return routability does in MIPv6, or IPsec in case of 
the HA) it won't be accepted. 

FWIW, MIPv6 could have used IP in IP tunnelling instead
of the HAO and routing header, but the WG decided against
this. Google draft-nordmark-hindsight ... for details.

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On Behalf Of
 > marcelo bagnulo
 > Sent: Monday, May 10, 2004 7:40 AM
 > To: Chan-Wah NG; IETF NEMO WG
 > Subject: RE: [nemo] Question on MR - CN
 > 
 > 
 > 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
 > >
 > >
 > > 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
 > >
 > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote:
 > > > Thierry Ernst wrote:
 > > >
 > > > >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.
 > > > >
 > > > >
 > > > 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
 > > > >
 > > >
 > > >
 > > >
 > >
 > 
 > 
 > 

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 10 May 2004 10:01:32 -0400

Hi Marcelo,

 > In my case, the question was generated by RFC 2003, since it 
 > states that
 > 
 > "Host implementations that are capable of receiving encapsulated IP
 > datagrams SHOULD admit only those datagrams fitting into one or more
 > of the following categories:
 > 
 > [...]
 >     -  The encapsulated (inner) datagram is addressed to a network
 >        interface belonging to the decapsulator"
 > 
 > This behavior is not coherent with the processing of MIPv6 
 > HoA destination
 > option and what you are describing i guess.

=> Well, 2003 is not even applicable to IPv6. Also
the HAO is not considered part of IP in IP tunnelling,
Although it's effectivley the same thing.

 > 
 > IMHO, the proper approach is to discard the encapsulated 
 > packets that don't
 > belong to an existent tunnel or that have been validated 
 > somehow, as you
 > mention, but RFC 2003 seems to state otherwise.

=> Agreed. 

 > 
 > Summarizing, I agree that CN shouldn't accept encapsulated 
 > packets that
 > don't belong to an existing tunnel, but that it is not what 
 > it is stated in
 > RFC 2003 (and AFAIK, most implementations don't accept them, 
 > as you mention)

=> Right. but I wouldn't worry about 2003 for IPv6.
A more relevant one is 2473.

 > 
 > The other question raised was why the CN shouldn't accept 
 > those packets, and
 > the reason for this is that it would even easier to spoof 
 > source addresses.

=> Yes.

Hesham

 > > De: Soliman Hesham [mailto:[email-masked]]
 > > Enviado el: lunes, 10 de mayo de 2004 14:26
 > > Para: [email-masked]; Chan-Wah NG; IETF NEMO WG
 > > Asunto: RE: [nemo] Question on MR - CN
 > >
 > >
 > > Hi,
 > >

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 10 May 2004 10:01:32 -0400

Hi Marcelo,

=> Agreed. 

=> Yes.

Hesham