RES: RES: RES: (ngtrans) IPv6 tranisition issues

Marcelo Barbosa Lima <mlima@cpqd.com.br> Mon, 06 January 2003 15:30 UTC

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05535 for <ngtrans-archive@lists.ietf.org>; Mon, 6 Jan 2003 10:30:37 -0500 (EST)
Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23029; Mon, 6 Jan 2003 08:33:09 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h06FX6um014277; Mon, 6 Jan 2003 07:33:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06FWl16008098 for <ngtrans-bumvof58w@sunroof.eng.sun.com>; Mon, 6 Jan 2003 07:32:47 -0800 (PST)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7+Sun/8.12.7/Submit) id h06FWl2I008097 for ngtrans-bumvof58w; Mon, 6 Jan 2003 07:32:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h06FWj16008090 for <ngtrans@sunroof.eng.sun.com>; Mon, 6 Jan 2003 07:32:45 -0800 (PST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL, v2.2) with ESMTP id h06FWrXq029656 for <ngtrans@sunroof.eng.sun.com>; Mon, 6 Jan 2003 07:32:53 -0800 (PST)
Received: from duque.cpqd.com.br (duque.cpqd.com.br [200.231.0.62]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07782 for <ngtrans@sunroof.eng.sun.com>; Mon, 6 Jan 2003 07:32:47 -0800 (PST)
Received: from fw-cpqd (dmz-int.cpqd.com.br [200.231.0.35]) by duque.cpqd.com.br (8.12.5/8.12.5) with SMTP id h06FWnto017420 for <ngtrans@sunroof.eng.sun.com>; Mon, 6 Jan 2003 13:32:49 -0200
Received: from gandalf.cpqd.com.br ([10.202.128.110]) by fw-cpqd; Mon, 06 Jan 2003 13:32:35 -0200 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RES: RES: RES: (ngtrans) IPv6 tranisition issues
Date: Mon, 06 Jan 2003 13:31:38 -0200
Message-ID: <D49EA2F934FFAD45B337C07A9753C00E017F55DF@MAILSRV1.aquarius.cpqd.com.br>
Thread-Topic: RES: RES: (ngtrans) IPv6 tranisition issues
Thread-Index: AcK1jow0hYmkI6LvQPOd5PMKDQJw3AABv7ZQ
From: Marcelo Barbosa Lima <mlima@cpqd.com.br>
To: Pekka Savola <pekkas@netcore.fi>
Cc: nick@arc.net.my, "Thakur, Anand" <Anand.Thakur@hpsglobal.com>, ngtrans@sunroof.eng.sun.com, engsg@i2r.a-star.edu.sg
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h06FWj16008091
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Marcelo Barbosa Lima <mlima@cpqd.com.br>
Content-Transfer-Encoding: 8bit

 I understand what you are saying. For this case, I think exaclty in manual configuration.  Using pre-shared secret or certificate digital. Really, the objetcive is to limit mobilility to only networks where the MN is permited (I dont want stranger laptops loging in my network :-). In public networks (cellular network, for example), authentication can be null (authentication would be take care to higher layers). One similar solution to IEEE 802.11b. In ARP and DHCP, this is impossible. So, in MIPv4 never can have this aditional security. Some authentication is more secure than no authentication. Manual key can be used in controlled and private enviroments. In the practice, nobody will want unkown hosts connected in your network. In public networks where we dont have pre-shared secrets or public Key Infrastructure, authentication can be done in higher layers. So, The possibility of implement authentication is real. This makes me to believe that MIPv6 is more secure than MIP4 !
regarding this subject.
Best Regards,

			Marcelo.

-----Mensagem original-----
De: Pekka Savola [mailto:pekkas@netcore.fi]
Enviada em: segunda-feira, 6 de janeiro de 2003 12:17
Para: Marcelo Barbosa Lima
Cc: nick@arc.net.my; Thakur, Anand; ngtrans@sunroof.eng.sun.com;
engsg@i2r.a-star.edu.sg
Assunto: Re: RES: RES: (ngtrans) IPv6 tranisition issues


On Mon, 6 Jan 2003, Marcelo Barbosa Lima wrote:
>    Sorry for my "market speak" but, of the RFC 2461:
> 
>    "Neighbor Discovery protocol packet exchanges can be authenticated
>    using the IP Authentication Header [IPv6-AUTH].  A node SHOULD
>    include an Authentication Header when sending Neighbor Discovery
>    packets if a security association for use with the IP Authentication
>    Header exists for the destination address.  The security associations
>    may have been created through manual configuration or through the
>    operation of some key management protocol.
> 
>    Received Authentication Headers in Neighbor Discovery packets MUST be
>    verified for correctness and packets with incorrect authentication
>    MUST be ignored.

Yeah, the language is wishy-washy -- when specifying, people didn't sit 
down and consider what it actually requires to make it work.
 
>    It SHOULD be possible for the system administrator to configure a
>    node to ignore any Neighbor Discovery messages that are not
>    authenticated using either the Authentication Header or Encapsulating
>    Security Payload.  The configuration technique for this MUST be
>    documented.  Such a switch SHOULD default to allowing unauthenticated
>    messages.
> 
>    Confidentiality issues are addressed by the IP Security Architecture
>    and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
>    ESP]."
> 
>   In a local enviroment is relatively more simple to create secutity
> associates between peers. Even PKI solution can be implemented. There
> are some purposes regarding authentication in Neighbor discovery
> protocol. I looked for a RFC/draft about it, but I did not find it.
> Please, who know where I can find it email me. If it is hard to
> implement, I think that it is not, because is more simple to establish
> SAs in local network. Regards,

How do you implement automatic keying when you don't have an IP address?
Therein is a bootstrapping problem.

Manual keying is possible but very burdensome, as you will also have to
create security associations with link-local multicast addresses.  Of
course, this is only possible in subnets where you know which nodes will
be there so pre-configuration will be possible (wrt. e.g. WLAN hotspots
are not so.)

The IETF web page is down at the moment, but check SEND working group 
page when it's available.  In particular check out these drafts:

draft-ietf-send-psreq-00.txt (under revision, new tentative version posted 
on the list)
draft-arkko-manual-icmpv6-sas-01.txt

> -----Mensagem original-----
> De: Pekka Savola [mailto:pekkas@netcore.fi]
> Enviada em: segunda-feira, 6 de janeiro de 2003 10:10
> Para: Marcelo Barbosa Lima
> Cc: nick@arc.net.my; Thakur, Anand; ngtrans@sunroof.eng.sun.com;
> engsg@i2r.a-star.edu.sg
> Assunto: Re: RES: (ngtrans) IPv6 tranisition issues
> 
> 
> On Mon, 6 Jan 2003, Marcelo Barbosa Lima wrote:
> > >Yes, in a typing fury I forgot/missed the IPv6 solution for mobility.
> > >IPv6 is streamlined and designed for mobility in mind. Again there are
> > >the patches in IPv4, although riddled with triangular routing issues.
> > >But then again is there anyone really into mobile IP? And I use NTT
> > >DoCoMo and likes in Japan as examples for this and not a 'hotspot' cafe
> > >answer on 802.11.
> > >
> > 
> >   In IPv4, attacks against ARP protocol (mobile IPv4 trusts in ARP
> > protocol) are easy to implment. DHCP can also be bypassed easily. So,
> > neighbour protocol with AH is more secure solution. Regards,
> 
> Less market speak, more technology, please.
> 
> Securing the neighbor protocol with AH is _hard_.
> 
> Please check out SEND working group.
> 
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords