RE: [Mip6] Bootstrapping DT solution draft

Gerardo Giaretta <Gerardo.Giaretta@TILAB.COM> Thu, 21 July 2005 13:29 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb6v-0001fX-KC; Thu, 21 Jul 2005 09:29:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb6u-0001f9-Iw for mip6@megatron.ietf.org; Thu, 21 Jul 2005 09:29:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29291 for <mip6@ietf.org>; Thu, 21 Jul 2005 09:29:10 -0400 (EDT)
Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvbaw-0007sX-Fs for mip6@ietf.org; Thu, 21 Jul 2005 10:00:15 -0400
Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IJZ00H8VBZC3Z@dns1.cselt.it> for mip6@ietf.org; Thu, 21 Jul 2005 15:26:00 +0200 (MEST)
Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 15:32:24 +0200
Date: Thu, 21 Jul 2005 15:28:55 +0200
From: Gerardo Giaretta <Gerardo.Giaretta@TILAB.COM>
Subject: RE: [Mip6] Bootstrapping DT solution draft
To: Christian Vogt <chvogt@tm.uka.de>
Message-id: <DA62A6E0CDD1B34A84557FF1AC850C5769E684@EXC01B.cselt.it>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: quoted-printable
Importance: normal
Priority: normal
Thread-Topic: [Mip6] Bootstrapping DT solution draft
thread-index: AcWNYudyFuboJdqvTAGUqbzwyWEJKgAjigQA
Content-Class: urn:content-classes:message
X-OriginalArrivalTime: 21 Jul 2005 13:32:24.0937 (UTC) FILETIME=[A1695D90:01C58DF8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: quoted-printable
Cc: mip6@ietf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org

Hi Christian,

thanks for your comments. Please see inline.. 

> 
> Hi Gerardo, hi DT members,
> 
> thanks for the bootstrapping I-D; you did a very good job!
> 
> Some comments (and questions) from my side:
> 
> (1)  The DT draft doesn't yet specify the backend AAA 
> protocol, e.g., a
> Diameter application.  Is this your next step?  (IMO, considering a
> split scenario makes sense only when you specify the AAA 
> protocol, too,
> because that AAA protocol---neither the DNS lookup nor the MN-HA IKEv2
> exchange---is affected by the split.)
> 

Actually the AAA backend is out of the scope of the DT. There is a WG
item (draft-ietf-mip6-aaa-ha-goals) that described the goals for the AAA
backend interface. A new version of this document will be released based
on draft-ietf-mip6-bootstrap-split-00 and based on the solution for
integrated scenario we are working on. Then I guess that definition of
the AAA protocol should be done by AAA and RADEXT working groups. 

> (2)  Draft-ietf-mip6-ikev2-ipsec-01.txt already defines how to
> dynamically assign a HoA during the IKEv2 handshake.  Why do you use
> different Configuration Payloads?
> 

We use the same attribute for HoA assignment by the HA (i.e.
INTERNAL_IP6_ADDRESS attribute).
We use a different attribute for HoA auto-configuration (i.e.
MIP6_HOME_PREFIX): this is because the MN needs to be provided by a
network prefix and its length. This is not the purpose of
INTERNAL_IP6_ADDRESS that provides an IPv6 address to the peer.

> (3) In order to contact DNS, the MN needs IP connectivity.  Is your
> assumption that the visited network (ASP/ASA) authorizes the MN for IP
> connectivity first, and the MN bootstraps Mobile IPv6 
> thereafter?  (This
> would preclude an all-in-one solution like, e.g., the one described in
> draft-le-aaa-diameter-mobileipv6-04.txt.)
> 

In split scenario network access authentication and authentication for
mobility service are performed indipendently. That is ASA and MSA are
different entities. The DT is currently working on an integrated
solution for the scenario you mention.

> (4) Are you assuming that the DNS server belongs to the MSA?  If not,
> the MN probably won't have an SA with the DNS server, so DNS requests
> are unauthenticated and DNS responses are not encrypted.  (Note that I
> am NOT talking about DNS updates here.)  As a consequence, information
> about the home topology is accessible to anybody.  Is this an issue?
> 

We believe this is not an issue, even if there has been discussion in
the DT about that. 

The HA address can be recovered by other means anyway. If you are
referring to possible DoS attacks, I think that not revealing the HA
address during the HA Address discovery is not a viable solution. IKEv2
has mechanisms built in to discourage DoS. Moreover, the Home Agents,
like any other server in the network, should be protected against DoS
attacks, e.g. by overprovision.

> (5)  The DNS server can store multiple HA addresses, so dynamic HA
> assignment is possible in principle.  Do you assume that the 
> DNS server
> is in charge of load balancing or that it can assign a HA 
> topologically
> close to the MN?  (Fault tolerance could be handled by DHAAD.)
> 

I think both are possible. Do you think we need more text about this in
the draft?


--Gerardo

> Allright then.
> 
> - Christian
> 
> --
> Christian Vogt, Institute of Telematics, University of Karlsruhe
> www.tm.uka.de/~chvogt/pubkey/
> 
> 
> 
> Gerardo Giaretta wrote:
> > Dear WG,
> >
> > the bootstrapping DT has submitted a solution draft. The document
> > defines how a Mobile Node can bootstrap MIPv6 operations from
> > non-topological information and pre-configured security 
> credentials. The
> > solution solves the boostrapping problem when the Mobile 
> Node's mobility
> > service is authorized by a different service provider than 
> basic network
> > access (i.e. split scenario).
> >
> > The draft can be found at
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
ing-split-
> > 00.txt.
> >
> > The DT is currently working on optimized solutions for integrated
> > scenario (i.e. mobility service and basic network access 
> are authorized
> > by the same entity).
> >
> > Please read the document and provide comments.
> >
> > Thanks and regards,
> >
> > --Gerardo (DT editor)
> 
> 
> 


Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin@tilab.com. Thank you
====================================================================

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6