Skip to main content

Using IPsec between Mobile and Correspondent IPv6 Nodes
draft-ietf-mip6-cn-ipsec-08

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from mext-chairs@ietf.org,Francis.Dupont@fdupont.fr,jeanmichel.combes@orange-ftgroup.com to mext-chairs@ietf.org
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
08 (System) post-migration administrative database adjustment to the Abstain position for Sam Hartman
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-04-27
08 (System) Document has expired
2010-04-26
08 Jari Arkko State Changes to Dead from IESG Evaluation::Revised ID Needed by Jari Arkko
2010-04-26
08 Jari Arkko
I have decided to move this draft to state Dead, because very little
has happened on it over time, and because in my personal opinion …
I have decided to move this draft to state Dead, because very little
has happened on it over time, and because in my personal opinion it
is still quite far from being ready.
2010-01-25
08 Jari Arkko
I finally had some time to read the new version in detail. I do have a number of question marks. At this point I'd like …
I finally had some time to read the new version in detail. I do have a number of question marks. At this point I'd like to discuss those issue with you before saying anything about what should be done with the document.

*Issue 1*: Section 6.2 says that IKE is run over home addresses. As you point out, this is different from RFC 3775, which said to run IKE over care-of addresses. The reason for the RFC 3775 recommendation was that a mobile node that does not yet have a SA or binding with the home agent could not use its home address this way. If it tried, home address validation check would drop the packets, because the packets do not contain a BU and there is no binding to this care-of address yet.

Now, my understanding is that your spec suffers from a limited version of the same problem. You can use IKE with home addresses, as long as the communication goes through the home agent. But you would be unable to initiate an IKE session with the correspondent node if the home agent was broken.

I'm asking partially because this would be something to explicitly talk about in the doc. And I'm also asking because home-free operation has been one of the requirements put forward in another context (air traffic control).

*Issue 2*: Section 8 says: "Although the protection of static addresses is not mandatory in IPsec or Home Addresses do not introduce a specific issue ..." First, I'm not sure I can parse the sentence. Second, I was under the impression that ability to match policies to an IP address is a mandatory part of the IPsec architecture. Can you explain what you meant?

*Issue 3*: You've done a good job in explaining the dangers of the protection scheme with dynamic addresses. Thanks for that. Still, this part gives me a headache. To me, its a major security hole. I'd rather live without it, or at least make it a SHOULD NOT.

*Issue 4*: I found the mobile node identification rules confusing in Sections 6.2 and 6.3, as well as being to weak. I would have wanted to see a SHOULD for home address based identification. This would also be more in line with the REQUIRE statements in 6.3.  On confusing, what does "use home address in mobile identification payloads" mean, exactly? The specific payload types etc should be listed.
2008-09-08
08 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko
2008-09-08
08 Jari Arkko State Change Notice email list have been change to mext-chairs@tools.ietf.org,Francis.Dupont@fdupont.fr,jeanmichel.combes@orange-ftgroup.com from mip6-chairs@tools.ietf.org,Francis.Dupont@fdupont.fr,jeanmichel.combes@orange-ftgroup.com
2008-08-25
08 (System) New version available: draft-ietf-mip6-cn-ipsec-08.txt
2008-05-08
08 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-05-08
08 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-03-14
08 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Abstain from Discuss by Sam Hartman
2008-03-11
08 Tim Polk
[Ballot discuss]
[This is a revised discuss; I am assuming Sam Hartman's discuss position in addition
to my original issues.  Sam's issues were appended as …
[Ballot discuss]
[This is a revised discuss; I am assuming Sam Hartman's discuss position in addition
to my original issues.  Sam's issues were appended as Part 2.]

Part1:

I would like to clarify the impact of this specification on implementations of RFC 3775.

As I understand it, using IPsec between the mobile node and correspondent node for
  (1) home address validation; and
  (2) protection of mobility signaling for route optimization
are out of scope for RFC 3775.

As a result, this specification has no impact on implementations of RFC 3775 unless they
also support the use of IPsec for (1) or (2) above.  Is this correct, or is there some impact
on implementations of RFC 3775 that do not use IPsec for these purposes...

(My interpretation is also that IPsec may be used for either of these purposes independently!
Is this correct, or is there a linkage I missed?)

I would also like to clarfiy the relationship of this specification and the various mobility RFCs.
As I interpret this document, support for RFC 3775 is mandatory.  However, this is not clearly stated.

Part 2:

I do not understand how this document meets its stated security
objectives.  In particular, this spec claims to be an alternative to
the procedures described in RFc 3775 for the validation of the home
address option and route optimization signaling.  Core to both of
these is the assumption that a correspondent can reasonably authorize
the home address.  IPsec provides peer entity authentication and
connectionless integrity for the packets.  However I don't understand
how IPsec helps with the authorization problem?  The CN knows the home
address has not been changed in transit, but how does it authorize
this address?  I guess for static home addresses you could configure a
mapping from IPsec phase 1 identity to home address on every CN.
However this document claims to support dynamic home addresses as
well.  I don't see how this mechanism actually meets the security
guarantees necessary to achieve the appropriate security objectives.

This document updates the procedures in section 9.5 and 9.3 of RFC
3775
so it needs to update that spec.  If there were an appropriate
extension mechanism then perhaps this would not update 3775, but as it
is, this spec creates situations where MUST and MUST NOT requirements
of 3775 are violated.


Section 6 is non-sensical:
>  seen at the transport or application layer, i.e., when the mobile
>  node uses its Home Address as the source of an IKE message, the
>  source address in the IP header can (should!) be a Care-of Address.

I'm not entirely sure what that's saying.  Perhaps that MIP6 should be
used for IKE.  If so, how do you validate the home address option for
IKE packets.  If it's saying something else, it makes no sense at all.

This document needs to describe appropriate PAD and SPD entries for
the IPsec configuration that is necessary to implement the spec.
2008-03-10
08 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Discuss from No Objection by Tim Polk
2008-02-23
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-02-23
07 (System) New version available: draft-ietf-mip6-cn-ipsec-07.txt
2007-11-22
08 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko
2007-11-22
08 Jari Arkko
I was unable to understand Section 6, and overall prefered the edits that J-M and me worked in Paris, as opposed to the ones in …
I was unable to understand Section 6, and overall prefered the edits that J-M and me worked in Paris, as opposed to the ones in -06.
2007-11-16
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-11-16
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-11-16
06 (System) New version available: draft-ietf-mip6-cn-ipsec-06.txt
2007-09-07
08 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk
2007-09-07
08 Jari Arkko State Change Notice email list have been change to mip6-chairs@tools.ietf.org,Francis.Dupont@fdupont.fr,jeanmichel.combes@orange-ftgroup.com from mip6-chairs@tools.ietf.org,Francis.Dupont@fdupont.fr,jeanmichel.combes@orange-ft.com
2007-09-07
08 (System) Removed from agenda for telechat - 2007-09-06
2007-09-06
08 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-09-06
08 Sam Hartman
[Ballot discuss]
I do not understand how this document meets its stated security
objectives.  In particular, this spec claims to be an alternative to
the …
[Ballot discuss]
I do not understand how this document meets its stated security
objectives.  In particular, this spec claims to be an alternative to
the procedures described in RFc 3775 for the validation of the home
address option and route optimization signaling.  Core to both of
these is the assumption that a correspondent can reasonably authorize
the home address.  IPsec provides peer entity authentication and
connectionless integrity for the packets.  However I don't understand
how IPsec helps with the authorization problem?  The CN knows the home
address has not been changed in transit, but how does it authorize
this address?  I guess for static home addresses you could configure a
mapping from IPsec phase 1 identity to home address on every CN.
However this document claims to support dynamic home addresses as
well.  I don't see how this mechanism actually meets the security
guarantees necessary to achieve the appropriate security objectives.

This document updates the procedures in section 9.5 and 9.3 of RFC
3775
so it needs to update that spec.  If there were an appropriate
extension mechanism then perhaps this would not update 3775, but as it
is, this spec creates situations where MUST and MUST NOT requirements
of 3775 are violated.


Section 6 is non-sensical:
>  seen at the transport or application layer, i.e., when the mobile
>  node uses its Home Address as the source of an IKE message, the
>  source address in the IP header can (should!) be a Care-of Address.

I'm not entirely sure what that's saying.  Perhaps that MIP6 should be
used for IKE.  If so, how do you validate the home address option for
IKE packets.  If it's saying something else, it makes no sense at all.

This document needs to describe appropriate PAD and SPD entries for
the IPsec configuration that is necessary to implement the spec.
2007-09-06
08 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2007-09-06
08 Russ Housley
[Ballot discuss]
Section 6 says:
  >
  > This document considers only IKE where it is used for mobility
  > purpose.  Peer addresses …
[Ballot discuss]
Section 6 says:
  >
  > This document considers only IKE where it is used for mobility
  > purpose.  Peer addresses (addresses IKE runs over) are the addresses
  > seen at the transport or application layer, i.e., when the mobile
  > node uses its Home Address as the source of an IKE message, the
  > source address in the IP header can (should!) be a Care-of Address.
  >
  Please reword using RFC 2119 language.  There is a big difference
  between "can" and "should."
2007-09-06
08 Russ Housley
[Ballot discuss]
Section 6 says:
  >
  > This document considers only IKE where it is used for mobility
  > purpose.  Peer addresses …
[Ballot discuss]
Section 6 says:
  >
  > This document considers only IKE where it is used for mobility
  > purpose.  Peer addresses (addresses IKE runs over) are the addresses
  > seen at the transport or application layer, i.e., when the mobile
  > node uses its Home Address as the source of an IKE message, the
  > source address in the IP header can (should!) be a Care-of Address.
  >
  Please reword using RFC 2119 language.  There is a big difference
  between "can" and "should."
2007-09-06
08 Russ Housley
[Ballot discuss]
Section 6 says:
  >
  > This document considers only IKE where it is used for mobility
  > purpose.  Peer addresses …
[Ballot discuss]
Section 6 says:
  >
  > This document considers only IKE where it is used for mobility
  > purpose.  Peer addresses (addresses IKE runs over) are the addresses
  > seen at the transport or application layer, i.e., when the mobile
  > node uses its Home Address as the source of an IKE message, the
  > source address in the IP header can (should!) be a Care-of Address.
  >
  Please reword using RFC 2119 language.  There us a big difference
  between "can" and "should."
2007-09-06
08 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-09-06
08 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-09-06
08 Tim Polk
[Ballot discuss]
I would like to clarify the impact of this specification on implementations of RFC 3775.

As I understand it, using IPsec between …
[Ballot discuss]
I would like to clarify the impact of this specification on implementations of RFC 3775.

As I understand it, using IPsec between the mobile node and correspondent node for
  (1) home address validation; and
  (2) protection of mobility signaling for route optimization
are out of scope for RFC 3775.

As a result, this specification has no impact on implementations of RFC 3775 unless they
also support the use of IPsec for (1) or (2) above.  Is this correct, or is there some impact
on implementations of RFC 3775 that do not use IPsec for these purposes...

(My interpretation is also that IPsec may be used for either of these purposes independently!
Is this correct, or is there a linkage I missed?)

I would also like to clarfiy the relationship of this specification and the various mobility RFCs.
As I interpret this document, support for RFC 3775 is mandatory.  However, this is not clearly stated.
2007-09-06
08 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2007-09-06
08 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-09-06
08 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2007-09-06
08 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-09-05
08 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2007-09-05
08 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-09-04
08 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we
understand this document to have NO IANA Actions.
2007-09-04
08 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-09-04
08 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2007-09-04
08 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-09-04
08 Lars Eggert
[Ballot comment]
Section 4., paragraph 1:
>    This document amends the Mobile IPv6 [RFC3775] section 9.3.1 by
>    adding a second …
[Ballot comment]
Section 4., paragraph 1:
>    This document amends the Mobile IPv6 [RFC3775] section 9.3.1 by
>    adding a second way (other than Binding Cache Entry check) to provide
>    Home Address Option validation.

  This sounds like this document should be marked as updating RFC3775.
2007-09-04
08 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-09-03
08 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-09-03
08 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2007-09-03
08 Jari Arkko No Last Call comments.
2007-08-31
08 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-08-21
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Glen Zorn
2007-08-21
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Glen Zorn
2007-08-17
08 Amy Vezza Last call sent
2007-08-17
08 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-08-17
08 Jari Arkko [Note]: 'AD Sponsored submission. There is no Document Shepherd.' added by Jari Arkko
2007-08-17
08 Jari Arkko Placed on agenda for telechat - 2007-09-06 by Jari Arkko
2007-08-17
08 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2007-08-17
08 Jari Arkko Ballot has been issued by Jari Arkko
2007-08-17
08 Jari Arkko Created "Approve" ballot
2007-08-17
08 Jari Arkko State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko
2007-08-17
08 Jari Arkko Last Call was requested by Jari Arkko
2007-08-17
08 (System) Ballot writeup text was added
2007-08-17
08 (System) Last call text was added
2007-08-17
08 (System) Ballot approval text was added
2007-08-17
08 Jari Arkko Intended Status has been changed to Proposed Standard from Experimental
2007-08-17
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-08-17
05 (System) New version available: draft-ietf-mip6-cn-ipsec-05.txt
2007-03-14
08 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko
2007-03-14
08 Jari Arkko
3rd AD review:

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

1. The security …
3rd AD review:

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 strong authentication is employed, 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.

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. If you agree with the or some other
edits with a similar intent, I can place the document for IESG
review even without a revision of the actual draft.

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.
2007-03-01
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-03-01
04 (System) New version available: draft-ietf-mip6-cn-ipsec-04.txt
2007-01-03
08 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko
2007-01-03
08 Jari Arkko
New AD review:

like the new applicability statement and other
changes you made in the draft. However, there
are still some issues from my previous …
New AD review:

like the new applicability statement and other
changes you made in the draft. However, there
are still some issues from my previous review
that were not addressed, including for instance
the normative references, negotiation of how
this mechanism is turned on, and a more detailed
explanation of the security implications of this
mechanism. Details later in this e-mail.

Also, as I went through the draft I wrote some
edits that would satisfy my review and let this
draft move forward. Feel free to use these
as a starting point or make your own edits;
they are provided as suggestions only:

http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits.txt
http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits-from-draft-ietf-mip6-cn-ipsec-03.diff.html

Technical:
>    -  when an alternate care-of address option is present and is not
>      checked using the state cookie mechanism [COOKIE], the alternate
>      care-of address MUST match the source address in the IP header or
>      the home address itself.  Any binding update which does not
>      fulfill this requirement MUST be rejected.
>    -  no care-of address test is required when ingress filtering can
>      reject fake care-of addresses from a rogue mobile node but a
>      correspondent node can use the return routability state cookie
>      procedure to get extra insurance as well as for the support of
>      real alternate care-of addresses.
We already talked about this...

I would suggest deleting the part about the cookie mechanism.
This allows your draft to become an RFC without this IMHO normative
reference. (And if/when you publish another RFC on the cookie
mechanism, its OK for that draft to update this RFC. And I am
willing to AD sponsor documents in this space. But I'd like to
do that on a document-by-document basis, not by approving
one document that points to all the others.)

In any case, my suggested edits contain a new
section about possible enhancements, with pointers
to some ideas. This would be OK.
>    When the home address is bound to a public key, for instance when the
>    home address is a Cryptographically Generated Addresses [RFC3972],
>    the strong authentication MAY be replaced by an address ownership
>    proof as described for instance in [IKECGA].
As above.

>    IPsec is far more secure than the return routability procedure, thus
>    it should be used where it is applicable.  So this document can
>    increase at least the overall security of Mobile IPv6.
This document should specify how IPsec is better or
different, not simply state its better.

My suggested edits have one attempt at such
a description.

Semi-technical:
>  In binding updates the new requirements are:
>    -  the H (home registration) and K (key management mobility
>      capability) bits MUST be cleared.
The former does not appear to be a new requirement. Suggest
deleting the entry, and stating later in the same section
"The use of the K (key management mobility capability)
bit with correspondent nodes is not defined. This bit
is always set to zero."

>    -  as ESP can only protect the payload, an alternate care-of address
>      option MUST be used in conjunction with ESP (cf. [RFC3775] section
>      11.7.1).
This is another requirement that is not new. Delete the
item.
>    -  "long" lifetime compatible with the IPsec policy (i.e., by default
>      up to the IPsec security association lifetime) MAY be granted.
Perhaps you should classify this as something else
than a new requirement, e.g., place it after the list
and formulate as:

"Note that a relatively "long" lifetime compatible with the IPsec policy
(i.e., by default up to the IPsec security association lifetime) MAY
be granted."
>    -  in order to avoid granting any extra privilege by a side effect of
>      using IPsec, the peers (i.e., the mobile and correspondent nodes)
>      may restrict the traffic selectors to the protection of mobility
>      signaling only.  This should be applied to any dubious cases,
>      including by default when security administration is known to be
>      too light.
I still do not understand this. Furthermore, it seems to
argue against the situation that you assumed in the
applicability statement. That is, you use this method
when you would be using IPsec anyway for some other
reason.

> When a packet carrying a home address option is protected by a
> >    suitable IPsec security association, the home address option SHOULD
> >    be considered valid.

>
> I think there should be a discussion somewhere (perhaps Section 2)
> about the type of SA creation procedure and trust that is required
> to make the above decision. See RFC 4449 Section 2 first two bullet
> items for an example, and consider saying something about whether
> this mechanism is applicable with BTNS or opportunistic IPsec.
>
> The implications may also be different for triangular routing
> and route optimization. It seems that all we need for triangular
> routing is that the original address (the one that you send
> traffic back to) was used in the IKE exchange. That is, a dynamic
> SA is needed, but it can be of any type. For route optimization,
> we'd like to know and trust the entity at the other end.

This comment from my previous review has not
been addressed.

> In binding updates the new requirements are:

>
> I would like to understand what happens when the peers use RFC 3775
> while at the same time for other reasons use IPsec between themselves,
> and ONE (not both) support the mechanism specified here. How do they
> know what they should do? Is there a missing negotiation step somewhere?

As above.

> If you cut away the state cookie reference (as suggested earlier),
> I would suggest that you include a statement similar to RFC 4449
> about the trust needed to take care-of addresses without verifying
> them.
As above.


Editorial:

> But any stronger mechanism (i.e., more secure than the
> return routability procedure) may be used, including of course IPsec
> (cf. [RFC3775] Appendix 3 "New Authorization Methods").
For readability, you should rewrite this as "This document
defines an alternative mechanism based on strong authentication
and IPsec."
>    The purpose of this document is not to replace the [RFC3775] return
>    routability procedure by the use of IPsec/IKE which has some
>    authentication requirements which make its universal deployment more
>    than unrealistic.
Again for readability, change to

  The purpose of this document is not to replace the [RFC3775] return
  routability procedure by the use of IPsec/IKE. It is unrealistic to
  expect credentials to be available for strong authentication between
  any pair of communication hosts.

Finally, the document should be checked for correct
capitalization of terms (such as message names) from
RFC 3775.
2007-01-02
08 Jari Arkko Intended Status has been changed to Experimental from Proposed Standard
2007-01-02
08 Jari Arkko State Change Notice email list have been change to mip6-chairs@tools.ietf.org,Francis.Dupont@fdupont.fr,jeanmichel.combes@orange-ft.com from mip6-chairs@tools.ietf.org
2007-01-02
08 Jari Arkko
MPTCP                                                  …
MPTCP                                                            F. Song
Internet-Draft                                                  H. Zhang
Intended status: Informational              Beijing Jiaotong University
Expires: September 14, 2017                                      H. Chan
                                                                  A. Wei
                                                    Huawei Technologies
                                                          March 13, 2017

                One Way Latency Considerations for MPTCP
                        draft-song-mptcp-owl-02

Abstract

  This document discusses the use of One Way Latency (OWL) for
  enhancing multipath TCP (MPTCP).  Several use cases of OWL, such as
  retransmission policy and crucial data scheduling are analyzed.  Two
  kinds of OWL measurement approaches are also provided and compared.
  More explorations related with OWL will be helpful to the performance
  of MPTCP.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  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."

  This Internet-Draft will expire on September 14, 2017.

Copyright Notice

  Copyright (c) 2017 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect

Song, et al.          Expires September 14, 2017              [Page 1]
Internet-Draft        OWL Considerations for MPTCP            March 2017

  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.


about the trust needed to take care-of addresses without verifying
them.

> >    When the home address is bound to a public key, for instance when the
> >    home address is a Cryptographically Generated Addresses [RFC3972],
> >    the strong authentication MAY be replaced by an address ownership
> >    proof.  In this case the public key MAY be transported by IKE from
> >    the mobile node to the correspondent node, for instance in a
> >    Certificate payload of type 11 ([IKEv2] section 3.6).  Auxiliary
> >    parameters MAY be transported in an Identification payload of type
> >    ID_KEY_ID...

This would work, but I worry about the lack of details here. How would
the peers know they are using RFC 3972 to authenticate in IKE? How are
the CGA parameters transported? Suggestion: if we can not provide
full details, leave this part to another document.

> >    -  in order to avoid granting any extra privilege by a side effect of
> >      using IPsec, the peers (i.e., the mobile and correspondent nodes)
> >      may restrict the traffic selectors to the protection of mobility
> >      signaling only.  This should be applied to any dubious cases,
> >      including by default when security administration is known to be
> >      too light.

I am not sure I follow. Can the specific vulnerability be documented
here? Note: if you only include mobility signaling then triangular
routing is not possible. And it would be surprising if regular payload
traffic protected by IPsec would caused privilege elevation, assuming
the peers were OK with doing IPsec for their traffic. Is there some
vulnerability related to the use of Mobile IPv6 in this case?

> >    But any stronger mechanism (i.e., more secure than the
> >    return routability procedure) MAY be used, including of course IPsec
> >    (cf. [RFC3775] Appendix 3 "New Authorization Methods").

I'm troubled by the "MAY" in this context. It does not appear
to be a direct quote from anywhere, and this document should
not grant rights to use "any" mechanism. It should state that
its defining a specific new mechanism, not anything about other
mechanisms.

> >    mobility signaling for routing optimizations.  The configuration

maybe "... for route optimization" (there's just one kind).

> >    This document uses the "MUST", "SHOULD", "MAY", ..., key words
> >    according to [RFC2119].  IKE terminology is copied from IKEv2
> >    [IKEv2].

Please use the standard template keyword statement:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

> >    send the packets via the home till a binding update is processed.

s/till/until/

> >    Auxiliary
> >    parameters MAY be transported in an Identification payload of type
> >    ID_KEY_ID...

Too many dots.
2006-08-03
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-08-03
03 (System) New version available: draft-ietf-mip6-cn-ipsec-03.txt
2006-07-05
08 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko
2006-07-05
08 Jari Arkko
July 3, 2006: Charter proposal for MIP6 posted to the WG list. Suggests that this document NOT be a part of the charter, but taken …
July 3, 2006: Charter proposal for MIP6 posted to the WG list. Suggests that this document NOT be a part of the charter, but taken to Experimental RFC status via the AD Sponsored route.
July 5, 2006: AD review posted to the WG list, with a number of specific issues raised. Needs another rev.
2006-06-19
08 Dinara Suleymanova
PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to …
PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes.

2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

Sufficient.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No concerns about the need for broader or additional reviews.

4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

None.

5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

Consensus about an alternative mechanism to Return routability for
securing the route optimization messages exists.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes.

8) Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(Note: the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

Yes.

9) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:

- Technical Summary

The I-D defines how IPsec can be used for securing the MIP6
(RFC3775) route optimization messages between an MN and CN. Return
routability testing (RRT) is the default method for MIP6 to enable route
optimization. This I-D proposes a mechanism that can be used when
an IPsec SA between the MN and CN exists instead of RRT.

- Working Group Summary

The I-D has been presented to the WG and discussed in WG meetings
in 2005. While there is not an overwhelming need for such a
solution, it does provide an alternative especially when there
exists an IPsec SA between the MN and CN.

- Protocol Quality

The I-D only defines how IPsec can be used for securing the RO
messages and no new protocol is defined.

- is the protocol already being implemented?

No.

- have a significant number of vendors indicated they plan to
implement the spec?

No.

- are there any reviewers (during the end stages) that merit
explicit mention as having done a thorough review that resulted
in important changes or a conclusion that the document was fine
(except for maybe some nits?)

No.
2006-06-16
08 Jari Arkko
MIP6 charter needs revision, this and a few other documents are not really listed in the current charter. The charter will be updated and then …
MIP6 charter needs revision, this and a few other documents are not really listed in the current charter. The charter will be updated and then this document can go forward.
2006-06-16
08 Jari Arkko Draft Added by Jari Arkko in state AD Evaluation
2005-12-21
02 (System) New version available: draft-ietf-mip6-cn-ipsec-02.txt
2005-06-27
01 (System) New version available: draft-ietf-mip6-cn-ipsec-01.txt
2005-01-11
00 (System) New version available: draft-ietf-mip6-cn-ipsec-00.txt