Subject: Re: [Mip6] Revised WG charter

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Sep 2006 16:12:58 +0300

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?
>
>> 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?

We can drop items that have passed IESG evaluation by the
time the charter becomes approved. The others I would
like to keep. This helps my IESG colleagues to match charter
items to the documents they are processing, avoids dangling
non-charter items if some of the work gets delayed, etc.

I intend to take the rechartering to IESG meeting on the
Sept 14th.

--Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Tue, 5 Sep 2006 11:08:47 -0700

> 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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Sep 2006 21:16:42 +0300

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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Sep 2006 22:30:08 -0500

James,

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

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Sep 2006 22:37:02 -0500

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

-Raj

On 8/31/06 1:04 PM, "ext James Kempf" <[email-masked]> wrote:

> Raj,
> 
> Some specific comments, mostly editorial.
> 
> 
>> 
>> 
>> Mobility for IPv6 (mip6)
>> 
>> Last Modified: 2006-08-26
>> 
>> Chair(s):
>> Basavaraj Patil <[email-masked]>
>> Gopal Dommety <[email-masked]>
>> 
>> Internet Area Director(s):
>> Jari Arkko <[email-masked]>
>> Mark Townsley <[email-masked]>
>> 
>> Internet Area Advisor:
>> Jari Arkko <[email-masked]>
>> 
>> Mailing Lists:
>> General Discussion: [email-masked]
>> 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.
>> 
> 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:
>> 
>> Nov 2006    Submit I-D 'Bootstrapping solution for split Scenario' to IESG
>> Jan 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for
> 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 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Sep 2006 22:30:08 -0500

James,

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Sep 2006 22:37:02 -0500

-Raj

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Sep 2006 09:14:25 -0700

See Kuntal's message and my response.

            jak

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Jari Arkko" <[email-masked]>; "James Kempf" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 06, 2006 8:30 PM
Subject: Re: [Mip6] Revised WG charter

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 07 Sep 2006 16:03:10 -0500

James,

Kuntal is mentioning revising RFC4285. This is a lot different from adding
text in the I-D: draft-ietf-mip6-whyauthdataoption explaining the issue(s)
with the current version of the spec.
I am not sure I follow what you suggested by looking at Kuntal's message and
your response.

If you are suggesting that algorithm agility be mentioned as an issue in the
whyauth I-D, I am okay with that.

-Raj

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Sep 2006 09:49:55 -0700

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 07, 2006 2:03 PM
Subject: Re: [Mip6] Revised WG charter

> whyauth I-D, I am okay with that.

Yes, that and the problem with key length that Kuntal mentioned. I think it 
might also be worthwhile have a more thorough security review to see if any 
other issues turn up.

         jak

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 20 Sep 2006 06:44:55 -0700

Hi all, 

A heads up to the list; I wanted to update you on the few issues left
against the draft. There are three main issues to solve (a couple more
less important ones). We discussed the main ones in the meeting. The DT
has agreed to solve them on the mailing list, i.e. leave it up to the
WG. 
In the following days I'll be sending out each issue separately and
either a suggested resolution or a question to the WG. 

We already know what each member in the DT thinks about the issues, so
this will be intended to poll the rest of the WG in order to decide. The
DT's opinions will be included in the issue analysis that I'll send out,
but I'll refrain from associating names to opionions of course. Please
stay tuned and provide your input to those discussions. 

Thanks,
Hesham