Subject: [Mip6] I-D ACTION:draft-ietf-mip6-cn-ipsec-04.txt

From: [email-masked]
Date: Thu, 01 Mar 2007 15:50:03 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobility for IPv6 Working Group of the IETF.

	Title		: Using IPsec between Mobile and Correspondent IPv6 Nodes
	Author(s)	: F. Dupont, J. Combes
	Filename	: draft-ietf-mip6-cn-ipsec-04.txt
	Pages		: 9
	Date		: 2007-3-1
	
Mobile IPv6 uses IPsec to protect signaling between the Mobile Node
   and the Home Agent.  This document defines how IPsec can be used
   between the Mobile Node and Correspondent Nodes for Home Address
   Option validation (aka. triangular routing) and protection of
   mobility signaling for Route Optimization.  The configuration details
   for IPsec and IKE are also provided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-cn-ipsec-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mip6-cn-ipsec-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Mar 2007 14:32:52 +0200

Francis, Jean-Michel,

I looked at the new revision. I wanted to move forward with
it, but it still has two issues:

1. The security considerations section does not, in my opinion,
    describe the full security implications. Basically, you simply
    state that IPsec/IKE based mechanism is the "best possible
    defense", and then you go on arguing why care-of addressing
    checking is not needed. I do not mind having the document say
    that the mechanism is strong, and I do not disagree
    with the specific points about the care-of address checking.
    However, the security considerations should describe the
    security rather than claim its the best possible one.

2. The possible enhancement section makes statements about
    various extension ideas and other IETF designs that I do not
    think you should be making. For instance, you state that
    BTNS is too weak but present no technical argument why
    this might be the case. It may well be the case, but its
    really not the place of this document to make broad claims,
    at least not if they are not supported by a detailed analysis.
    This section should also not employ keywords, to avoid
    interpreting a list of enhancement ideas as implementation
    requirements.

Since I would rather move forward than keep this document on
my table forever, please find attached suggested edits that
take care of the above issues. They are based on a merge of
your current text and the earlier text that I proposed when
I looked at the document the last time. If you agree with the or
some other edits with a similar intent, I can place the document
for IESG review immediately. Otherwise we'll probably have to
go to the next revision and continue discussing.

Replace two first paragraphs of Section 7 with this:

   The Mobile IPv6 Route Optimization security design background
   document [RFC4225] describes the unauthorized creation of Binding
   Cache entries as the main avenue of attack.  The authentication and
   authorization of the Mobile Node provided by IPsec/IKE is a strong
   defense against this threat.

   Where the means to create suitable IPsec security associations
   exist, this mechanism provides origin authentication, integrity
   protection, replay protection and optional confidentiality services
   for the Mobile IPv6 signalling. This improves the security over
   RFC 3775 route optimization, as the signaling packets in the latter
   are vulnerable to man-in-the-middle attacks. The implications of
   this vulnerability are subtle, however, given that an attacker in
   the same position is also capable of seeing all the payload packets
   and could launch other attacks with similar implications. For
   instance, such an attacker could see or modify the contents of
   payload packets not protected with end-to-end security and cause
   denial-of-service for others. However, the RFC 3775 mechanism
   allows such attacks in a short time window even after the attacker
   is no longer in a position to see the payload packets
   themselves. The mechanism defined in this specification removes
   this vulnerability, and is also secure independently of the
   possible vulnerabilities related to payload packets.

   However, unlike RFC 3775 this mechanism should only be used when
   the correspondent node has good reason to trust the actions of the
   mobile node. In particular, the correspondent node needs to be
   certain that the mobile node will not launch flooding attacks
   against a third party as described in [RODESIGN]. Without such
   trust the only protection comes from the application of ingress
   filtering in the network where the attacker resides. However, at
   the moment ingress filtering has not been universally deployed.
   This mechanism is vulnerable to flooding attacks as it does not
   verify the validity of a claimed new care-of address. Note,
   however, the following:

   -  The attacker has to be the Mobile Node itself, i.e., the IPsec/IKE
      peer, which is supposed to be the subject of a minimal level of
      trust.

   -  The attack can be traced back to the Mobile Node.

Replace Section 9 with this:

   A number of potential enhancements of this method are possible,
   including, for instance, various mechanisms for verification of
   Care-of Addresses or use of addresses bound to keys.  [ROENC]
   describes many proposals for the general Route Optimization problem.

   [COOKIE] is an alternate approach to testing Care-of Addresses.

   When the Home Address is bound to a public key, for instance when the
   Home Address is a Cryptographically Generated Addresses [RFC3972],
   [IKECGA] describes an alternative approach to the use of strong
   authentication.

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 14 Mar 2007 17:36:51 +0100

Hello could you comment on the following
very short I-D?

Thanks in advance.
Regards,

pars mutaf

----------------8<  cut here  8<--------------------

Network Working Group                                         Pars Mutaf
Internet-Draft                                     Institut National des
Intended status: Informational                        Telecommunications
Expires: September 15, 2007                               March 14, 2007

                       Disposable home addresses
                        draft-mutaf-dhoa-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 15, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The "home address" in Mobile IPv6 should be considered as private
   information, as it allows access to a mobile host regardless of its
   location.  This document presents a discussion of "disposable home
   addresses" for Mobile IPv6.

Mutaf                  Expires September 15, 2007               [Page 1]

Internet-Draft          Disposable home addresses             March 2007

1.  Introduction

   Inspired from [TDIGITS] [DPN], this document presents a discussion of
   "disposable home addresses" in Mobile IPv6.

   A mobile host can have multiple home addresses in the same or
   different home networks[?].  This has important benefits in terms of
   privacy and security.

   The host can distribute different home addresses to different
   entities.  Later, if one of the addresses is abused (for example, for
   spam, DoS attack, or location discovery), then that home address can
   be disposed i.e., destroyed by its owner.

   Techniques for distributing disposable home addresses falls out of
   this document's scope.  They can be reliably shared with "a priori"
   trusted parties using a technology like Bluetooth.  Or, one can use
   [PIQ].

2.  Security considerations

   TBD.

3.  IANA considerations

   None.

4.  Conclusion

   This document presented a discussion of disposable home addresses.

5.  Informative References

   [DPN]      Disposable phone numbers, "URL:
              http://dpn.sourceforge.net/".

   [PIQ]      Mutaf, P., "Private information queries (Problem
              Statement)", draft-mutaf-piqproblem-00.txt (work in
              progress), 2007.
              URL:
http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-00.txt

   [TDIGITS]  Tossable Digits, "URL: http://www.tossabledigits.com/".

Mutaf                  Expires September 15, 2007               [Page 2]

Internet-Draft          Disposable home addresses             March 2007

Author's Address

   Pars Mutaf
   Institut National des Telecommunications

   Email: [email-masked]

Mutaf                  Expires September 15, 2007               [Page 3]

Internet-Draft          Disposable home addresses             March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Mutaf                  Expires September 15, 2007               [Page 4]