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