Subject: Re: [MEXT] [IPsec] Roadmap doc

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 23 Oct 2008 18:24:23 +0200

Hi,                                                [mext added in CC]

"Sheila Frankel" <[email-masked]> writes:

> 7.  Outgrowths of IPsec/IKE
>    7.1.  IPComp (Compression)
>    7.2.  IKEv2 Mobility and Multihoming (MobIKE)
>    7.3.  Better-than-Nothing Security (Btns)
>    7.4.  Kerberized Internet Negotiation of Keys (Kink)
>    7.5.  IPsec Secure Remote Access (IPSRA)
>    7.6.  IPsec Keying Information Resource Record (IPsecKEY)
> 8.  Other Protocols that use IPsec/IKE
>    8.1.  Mobile IP (MIPv4 and MIPv6)

IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses
IPsec/IKE for its protection but it also has some very tight
interactions with IKE/IPsec/[PF_KEY] and for that reason, specific
requirements:

- configuration via IKEv2 (various RFC)
- bootstrapping and efficient handling of movement in IPsec/IKE context
  (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a
  follow-up of draft-sugimoto-mip6-pfkey-migrate-04) 

The problem is that this last item sits in the middle of the field with
IPsec WG on one side and MIPv6 on the other; each side considering that
it should be handled by the other.

At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026,
...) have expectations on the behavior in IPsec/IKE environments but
IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support
those requirements. This is currently making progress outside any
working group. 

In the end, I am wondering where this item stand w.r.t the roadmap
document. I know that it is not in the initial set of work items of the
WG but this does not prevent clarifying the position of the WG on it in
the doc, does it?

>    8.2.  Open Shortest Path First (OSPF)
>    8.3.  Host Identity Protocol (HIP)
>    8.4.  Extensible Authentication Protocol (EAP) Method Update (EMU) 10
>    8.5.  Stream Control Transmission Protocol (SCTP)
>    8.6.  Fibre Channel
> 9.  Security Considerations
> 10.  IANA Considerations
> 11. References
>    11.1. Normative References
>    11.2. Informative References
>
> Sections 1 and 2 will contain introductory material about IPsec and
> IKE: their functions, placement in the stack, inter-relationships,
> etc.
>
> The rest of the doc will basically be a list of RFCs, with a brief
> description of each. For the cryptographic algorithms, each section
> will describe where each type of algorithm is used within IPsec and/or
> IKE. For each algorithm, the following information will be included:
> whether it applies to IPsec, IKE, or both; requirement level (MUST
> etc.); special considerations (e.g. cannot be used with manual
> keying); how widely/commonly it is deployed. Section 8 (other
> protocols that use IPsec/IKE) will very briefly mention the context in
> which each protocol and/or RFC uses IPsec/IKE.
>
> Questions for the list:
> 1) Are there any other topics that should be discussed?

the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be
handled ;-)

Cheers,

a+

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 24 Oct 2008 23:04:33 +0800

Hello, all

We also have wrote this draft
http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-02.txt
and present in mip6 working group before several time.
and won the support from the floor, but no in the top priority list of
the current mext WG.

Regards,

-Hui

2008/10/24 Yaron Sheffer <[email-masked]>

> Hi Sheila, Arnaud,
>
> First, I am happy with the outline as presented here, including the 24XX
> documents. If anything, it may be too ambitious (i.e. lengthy).
>
> Regarding the interactions of MIP6 with IKE/IPsec:
>
> - The Roadmap document should cover these areas, just as it covers other
> consumers of this technology. But despite its (unfortunate) name, I don't
> see the document as a future-looking position statement of the WG, but
> rather as documentation of completed work.
>
> - As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy
> today with documents that have far wider applicability to the IPsec
> community. _If_ there is strong interest in these issues from a specific
> community of people, perhaps the way to go about it is with a dedicated
> design team.
>
> Thanks,
>        Yaron
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Arnaud Ebalard
> Sent: Thursday, October 23, 2008 18:24
> To: Sheila Frankel
> Cc: [email-masked]; IETF MEXT WG ML
> Subject: Re: [IPsec] Roadmap doc
>
> Hi,                                                [mext added in CC]
>
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
>
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 24 Oct 2008 11:48:50 +0200

Hi Sheila, Arnaud,

Thanks,
	Yaron

-----Original Message-----

Hi,                                                [mext added in CC]

Cheers,

a+