Vijay Devarapalli | 1 Sep 2006 16:47

[Fwd: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type]

FYI.

-------- Original Message --------
Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type
Date: Fri, 01 Sep 2006 00:07:23 +0200
From: Hannes Tschofenig <Hannes.Tschofenig <at> gmx.net>
To: dime <at> ietf.org

Hi all,

we have had long discussions about the App-ID vs. Service-Type usage for
Diameter MIPv6 Bootstrapping.

It is time to see what the group thinks. Please indicate whether you
prefer (1) an App-ID or (2) a Service-Type solution for

(a) NAS-to-AAAH communication (as required by the integrated scenario;
as one part of the solution component)

(b) HA-to-AAAH communication (as used by the split scenario and the
integrated scenario)

It might be useful to state a reason for your decision.

Please also indicate whether some aspects are still unclear to you.

Ciao
Hannes

_______________________________________________
(Continue reading)

Ozgur B. Akan | 1 Sep 2006 20:29
Picon
Favicon

CFP-NETWORKING2007: 6th IFIP International Conference on Networking

We apologize in advance if you receive multiple copies of this CFP.

**********************************************************************
********                   Networking 2007                    ********
******                                                          ******
****    IFIP Technical Committee on Communication Systems (TC6)   ****
**               International Conference on Networking             **
*                                                                    *
*                          May 14-18, 2007                           *
*              Georgia Tech Hotel, Atlanta, Georgia, USA             *
*                                                                    *
*                   http://www.ifip-networking.org                   *
*                                                                    *
*                          CALL FOR PAPERS                           *
**********************************************************************

Networking  2007  is  the  sixth  event in  a series of  International
Conferences on Networking,  sponsored by  the IFIP Technical Committee
on Communication  Systems (TC 6).  The  main  objectives of Networking
2007  are to  bring  together  active  and  proficient  members of the
networking community,  from both  academia  and  industry,  to discuss
recent   advances   in   this   broad   and   fast-evolving  field  of
telecommunications,  and to highlight key-issues,  identify trends and
refresh vision in the field of telecommunications.

The conference objectives will be  pursued through technical sessions,
keynote talks,  and tutorials offered  by invited experts,  as well as
panel  discussions  on  hot topics.  The  technical  sessions  will be
structured into three tracks.  Authors are  encouraged  to submit full
papers describing original, previously unpublished, complete research,
(Continue reading)

contact | 1 Sep 2006 20:21

[CFP] NTMS2007 : 1th International Conference on New Technologies, Mobility and Security

Dear Colleagues,

Please feel free to send this CFP to your friends and colleagues that
might be interested in the topics of NTMS&rsquo;2007 International
Conference on New Technologies, Mobility and Security.

This message is cross-posted to several lists. We apologize for
multiple copies.

--------------------- CALL FOR PAPERS - NTMS 2007
----------------------------------
1th International Conference on New Technologies, Mobility and
Security (NTMS 2007)
 Technically co-sponsored by IFIP and IEEE France Computer Section
 April 30 to May 3, 2007 - Beirut, Lebanon
 http://www.ntms2007.org
-------------------------------------------------------------------------------------

NTMS'2007 aims at fostering advances in the areas of New
Technologies, Wireless Networks, Mobile Computing, Ad hoc and Ambient
Networks, QoS, Network Security and E-commerce, to mention a few, and
provides a dynamic forum for researchers, students and professionals
to present their state-of-the-art research and development in these
interesting areas. 
The event will be combined with tutorial sessions and workshops.
Tutorials will precede the main program, aiming at the dissemination
of mature knowledge and technology advances in the field. Two or more
Workshops will immediately follow the main conference, offering the
opportunity for a more focused exchange of ideas and presentation of
on-going research relevant to selected topics. During NTMS'2007, demo
(Continue reading)

QIU Ying | 4 Sep 2006 08:36
Picon

Re: Revised WG charter


Hi, Raj

As the solution of firewall is one of the targets in the new charter, how 
about to review again the solution draft-qiu-mip6-mobile-firewall?

The draft protects the mobile node in different perspective from RFC4487. 
RFC4487 focuses on how to let a mobile node goes though a firewall. 
Correspondingly, the draft-qiu-mip6-mobile-firewall pays the attention on 
how to protect a mobile node continuously while MN roaming. The solution 
meets the scenario described in section 5.1, RFC 4487.

I am asking the IETF secretary to reactive the draft for discussing.

Regards
Qiu Ying

> ----------------------------------------------------------------------
>
> Date: Wed, 30 Aug 2006 19:43:35 -0500
> From: Basavaraj Patil <basavaraj.patil <at> nokia.com>
> Subject: [Mip6] Revised WG charter
> To: <mip6 <at> ietf.org>
> Message-ID: <C11B9AE7.233DF%basavaraj.patil <at> nokia.com>
> Content-Type: text/plain; charset="US-ASCII"
>
>
> Hello,
>
> Below is the revised WG charter (based on discussion at IETF66 and WG ML
(Continue reading)

Jari Arkko | 4 Sep 2006 15:12

Re: Revised WG charter

James Kempf wrote:

>>
>> - Produce a design rationale that documents the historical
>>   thinking behind the introduction of an alternative security
>>   mechanism, the Authentication Protocol (RFC 4285).
>>
>
> Actually, there are some technical problems with RFC 4285. There is no
> algorithm agility, for example, so if cryptanalysis continues to chip
> away at SHA1, the security will deteriorate. I think it might be
> worthwhile to revisit RFC 4285 if the WG really believes there is
> value in it.

The intent for this work item was not to start a
reclassification or redesign of RFC 4285, or
act as a motivation for new work. It was
intended to produce a document that acts as
historical record of the thinking. Possibly
along with a list of concerns raised against
the method. Does that make sense?

>>
>> Done          Submit I-D 'MIPv6 operation with IKEV2 and the revised
>>        IPsec Architecture' to IESG for publication as a
>>        Proposed Standard.
>>
>
> If this is complete, then why is it in the milestones?
>
(Continue reading)

James Kempf | 5 Sep 2006 20:08

Re: Revised WG charter

>> Actually, there are some technical problems with RFC 4285. There is no
>> algorithm agility, for example, so if cryptanalysis continues to chip
>> away at SHA1, the security will deteriorate. I think it might be
>> worthwhile to revisit RFC 4285 if the WG really believes there is
>> value in it.
>
> The intent for this work item was not to start a
> reclassification or redesign of RFC 4285, or
> act as a motivation for new work. It was
> intended to produce a document that acts as
> historical record of the thinking. Possibly
> along with a list of concerns raised against
> the method. Does that make sense?
>

A list of concerns ought to include the technical issues with the current 
document, as well as the architectural issues that were discussed during the 
WG discussion prior to publication.

        jak 
Jari Arkko | 5 Sep 2006 20:16

Re: Revised WG charter

James Kempf wrote:

> A list of concerns ought to include the technical issues with the
> current document, as well as the architectural issues that were
> discussed during the WG discussion prior to publication.

Yes.

--jari
Behcet Sarikaya | 6 Sep 2006 19:43
Picon
Favicon

Re: Conclusion of the consensus call related to the bootstrapping I-Ds

Hi Raj,
  I don't have any objection to your mail. I would like to point out a problem in
This draft defines new DHCPv6 options. I believe they are to be used in Stateless DHCP service defined in RFC 3736. This RFC forsees some new options to be defined in the future.
I suggest  the draft be modified to incorporate the above.
 
Regards,
 
--behcet

----- Original Message ----
From: Basavaraj Patil <basavaraj.patil <at> nokia.com>
To: ext James Kempf <kempf <at> docomolabs-usa.com>; "Chowdhury, Kuntal" <kchowdhury <at> starentnetworks.com>; Alper Yegin <alper.yegin <at> yegin.org>; mip6 <at> ietf.org
Sent: Tuesday, August 22, 2006 4:13:11 PM
Subject: Re: [Mip6] Conclusion of the consensus call related to the bootstrapping I-Ds

Hi James,

Stepping back from the specifics of the documents that we have today in the
WG w.r.t bootstrapping, I believe what the WG is chartered (which needs to
be updated BTW), is to develop a solution or solutions for bootstrapping
MIP6. I think we disccovered fairly early on that one bootstrapping solution
does not fit all environments. We are now even considering adopting Vijay's
draft which specifies bootstrapping in the case of the use of the
authenication protocol. But that's not the point here.

The WG direction is to develop a set of bootstrapping solutions that can be
used in various deployment scenarios. The scenarios that we have specified
in the WG today are based on the use of IKE for bootstrapping for the cases
that we call split and integrated. The issue about whether the DHCP options
should be specified within the integrate d scenarios document or separately
is simply a matter of how we split the documents.
Consensus was that keeping the DHCP options is preferred because of various
reasons (as has been discussed at length).

My recommendation is that we move forward with the set of existing I-Ds
which include the problem statement, Split scenario, Integrated scenario,
and DHCPv6 options.

W.r.t what 3GPP2 really wants from the integrated scenarios I-D, I believe
they require the IKE based bootstrapping solution for MIP6 and not just the
DHCP options.

-Raj


On 8/22/06 2:41 PM, "ext James Kempf" <kempf <at> docomolabs-usa.com> wrote:

> Raj,
>
> I'm not questioning the need for the document. What I'm asking is whether
> the document, as it stands, is consistent with the direction the WG wants to
> go in, given the consensus decision not to include the DHCP options into it.
> It seems to me that the direction is for the various pieces of the
> intergrated solution as separate documents.
>
> Regarding the 3GPP dependency, do they really want the system description
> part or are they really interested in the relay to server options?
>
>             jak
>
>
> ----- Original Message -----
> From: "Basavaraj Patil" <basavaraj.patil <at> nokia.com>
> To: "ext James Kempf" <kempf <at> docomolabs-usa.com>; "Chowdhury, Kuntal"
> <kchowdhury <at> starentnetworks.com>; "Alper Yegin" <alper.yegin <at> yegin.org>;
> <mip6 <at> ietf.org>
> Sent: Tuesday, August 22, 2006 12:13 PM
> Subject: Re: [Mip6] Conclusion of the consensus call related to the
> bootstrapping I-Ds
>
>
>>
>> Having spent a few months on deliberating how DHCP options required for
>> bootstrapping be specif ied, lets not go back in time and start discussing
>> if
>> the intergrated scenarios I-D is necessary or not.
>>
>> When the design team was formed, the conclusion after the completion of
>> the
>> split scenarios I-D was that a solution for the integrated scenario is
>> needed as well and hence the creation of the WG I-D.
>>
>> I have also been told by 3GPP2 (liaison) that they have a dependency on
>> the
>> integrated scenarios I-D.
>>
>> Hence I would recommend that we stop this discussion and lets work on
>> completing the bootstrap solutions work.
>>
>> -Raj
>>
>>
>
>


_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6IV>

_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
Basavaraj Patil | 7 Sep 2006 05:30
Picon

Re: Revised WG charter


James,

If you could provide text describing the issue, I would be glad to
incorporate it into the I-D.

-Raj

On 9/5/06 1:16 PM, "ext Jari Arkko" <jari.arkko <at> piuha.net> wrote:

> James Kempf wrote:
> 
>> A list of concerns ought to include the technical issues with the
>> current document, as well as the architectural issues that were
>> discussed during the WG discussion prior to publication.
> 
> Yes.
> 
> --jari
> 
Basavaraj Patil | 7 Sep 2006 05:37
Picon

Re: Revised WG charter


Thanks. I have incorporated the changes in a revised version.

-Raj

On 8/31/06 1:04 PM, "ext James Kempf" <kempf <at> docomolabs-usa.com> wrote:

> Raj,
> 
> Some specific comments, mostly editorial.
> 
> 
>> 
>> 
>> Mobility for IPv6 (mip6)
>> 
>> Last Modified: 2006-08-26
>> 
>> Chair(s):
>> Basavaraj Patil <basavaraj.patil <at> nokia.com>
>> Gopal Dommety <gdommety <at> cisco.com>
>> 
>> Internet Area Director(s):
>> Jari Arkko <jari.arkko <at> piuha.net>
>> Mark Townsley <townsley <at> cisco.com>
>> 
>> Internet Area Advisor:
>> Jari Arkko <jari.arkko <at> piuha.net>
>> 
>> Mailing Lists:
>> General Discussion: mip6 <at> ietf.org
>> To Subscribe: https://www.ietf.org/mailman/listinfo/mip6
>> Archive: http://www.ietf.org/mail-archive/web/mip6/index.html
>> 
>> Description of Working Group:
>> 
>> Mobile IPv6 (MIP6) specifies routing support which permits an IPv6
>> host to continue using its home address as it moves around the
>> Internet, enabling continuity of sessions. Mobile IPv6 supports
>> transparency above the IP layer, including maintenance of active TCP
>> connections and UDP port bindings. The base specifications for Mobile
> 
> So does this mean the Mobile IP doesn't support SCTP or DCCP?
> 
> I'd suggest the following:
> 
>     including maintenance of active transport level sessions.
> 
>> IPv6 consist of:
>> 
>>     o RFC 3775
>>     o RFC 3776
>> 
>> The primary goal of the MIP6 working group will be to enhance base
>> IPv6 mobility by continuing work on developments that are required for
>> wide-scale deployments. Additionally the working group will ensure
>> that any issues identified by implementation and interoperability
>> experience are addressed, and that the base specifications are
>> maintained. The group will also produce informational documentation,
>> such as design rationale documents or description of specific issues
>> within the protocol.
>> 
>> Deployment considerations call for work to reduce per-mobile node
>> configuration and enrollment effort, solutions to enable dual-stack
>> operation, mechanisms to support high-availabity home agents, and ways
>> to employ Mobile IPv6 in the presence of firewalls.
>> 
>> Work items related to base specification maintenance include:
>> 
>> - Create and maintain an issue list that is generated on the basis of
>>   implementation and interoperability experience. Address specific
>>   issues with specific updates or revisions of the base
>>   specification.  This work relates only to corrections and
>>   clarifications. The working group shall not revisit design
>>   decisions or change the protocol.
>> 
>> - Update RFC 3776 to specify the usage of IKEv2 for the establishment
>>   of the IPsec SA between the MN and HA. This work also provides a
>>   way for a mobile node to change its home address or employ multiple
>>   home addresses as needed.
>> 
>> - Update the IANA considerations of RFC 3775 to allow extensions for
>>   experimental purposes as well passing of optional vendor-specific
>>   information.
>> 
>> Work items related to large scale deployment include:
>> 
>> - Bootstrapping Mobile IPv6: A bootstrapping mechanism is intended to
>>   be used when the device is turned on the very first time and
>>   activates Mobile IPv6, or periodically such as when powering
>>   on. The WG should investigate and define the scope before solving
>>   the problem.
>> 
>>   Work on the problem statement and the solutions needed for various
>>   deployment scenarios. Work with other WGs such as DHC for defining
>>   the options needed for bootstrapping.
>> 
>> - Capture the AAA requirements needed for bootstrapping and
>>   deployment, and work with the Radext and DiME WGs on the solutions.
>> 
> 
> I think this addresses Kuntal's comment.
> 
>> - A Solution for MIP6 session continuity for dual stack hosts which
>>   attach to IPv4 access networks. Additionally provide a mechanism
>>   for carrying IPv4 packets via the Home agent for MIP6 capable
>>   dual-stack hosts. This work will be done in collaboration with the
>>   NEMO WG.
>> 
>> - A protocol based solution for enhancing the reliability of home
>>   agents and a method to force a host to switch home agents.
>> 
>> - A mechanism to force an MN to switch the HA that is currently
>>   serving it. This is required in deployments where the HA may need
>>   to be taken offline for maintenance.
>> 
>> - Work on solutions to deal with firewalls and the problems that
>>   firewalls cause as identified in RFC 4487.
>> 
>> Work items related to informational documentation include:
>> 
>> - Produce a problem statement relating to location privacy and the
>>   use of Mobile IPv6. Work with the IRTF MOBOPTS RG on developing the
>>   solution.
>> 
>> - Produce a design rationale that documents the historical
>>   thinking behind the introduction of an alternative security
>>   mechanism, the Authentication Protocol (RFC 4285).
>> 
> 
> Actually, there are some technical problems with RFC 4285. There is no
> algorithm agility, for example, so if cryptanalysis continues to chip away
> at SHA1, the security will deteriorate. I think it might be worthwhile to
> revisit RFC 4285 if the WG really believes there is value in it.
> 
>> It should be noted that some of the features that are directly related
>> to Mobile IPv6 are being worked on in the MONAMI6, MIPSHOP, and NEMO
>> working groups. The specific extensions from these groups are out of
>> scope for the MIP6 working group. In particular, all optimizations are
>> out of scope. However, MIP6 may assist these groups when they use
>> features listed above and have requirements on them.
>> 
>> Milestones:
>> 
>> Done          Submit I-D 'MIPv6 operation with IKEV2 and the revised
>>        IPsec Architecture' to IESG for publication as a
>>        Proposed Standard.
>> 
> 
> If this is complete, then why is it in the milestones?
> 
>> Sep 2006    Submit I-D 'Motivation for Authentication I-D' to IESG
>>        for publication as Informational.
>> 
>> Sep 2006    Submit I-D 'Bootstrapping solution for Integrated Scenario'
>>        to IESG for publication as a Proposed Standard.
>> 
>> Oct 2006    Submit I-D 'Goals for AAA HA Interface' to IESG for
>>        publication as Informational.
>> 
>> Oct 2006    Submit I-D 'Address Location Privacy and Mobile IPv6 Problem
>>        Statement' to IESG for publication as Informational.
>> 
>> Nov 2006    Submit I-D 'Bootstrapping solution for split Scenario' to IESG
>>        for publication as a Proposed Standard.
>> 
>> Nov 2006 Submit I-D 'DHCP Options for Home Information Discovery in
>>        MIPv6' for publication as a proposed standard.
>> 
>> Dec 2006    Submit I-D 'Home agent reliability' to IESG for publication
>>        as a Proposed Standard.
>> 
>> Dec 2006    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
>>        publication as a Proposed Standard.
>> 
>> Dec 2006 Submit I-D 'Mobility Header Home Agent Switch Message' to
>>         IESG for publication as a Proposed Standard.
>> 
>> Jan 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for
>>        publication as a Proposed Standard.
>> 
>> Apr 2007    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
>>        for publication as Informational.
>> 
>> May 2007    Submit I-D(s) related to specific updates and corrections
>>        of RFC 3775 to IESG for publication as Proposed Standard.
>> 
> 
> Some of these are very short term, like the Sept. ones. If the charter is
> approved by the end of Sept, they will be complete before the charter is. Is
> it really necessary to list those?
> 
>         jak 
> 

Gmane