IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Margaret Wasserman |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the Yes position for Russ Housley |
2006-03-13
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-03-03
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-03-03
|
08 | Amy Vezza | IESG has approved the document |
2006-03-03
|
08 | Amy Vezza | Closed "Approve" ballot |
2006-03-03
|
08 | Russ Housley | State Changes to Approved-announcement to be sent from IESG Evaluation by Russ Housley |
2006-03-03
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley |
2006-02-24
|
08 | (System) | New version available: draft-ietf-mobike-protocol-08.txt |
2006-02-07
|
08 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2006-02-02
|
08 | Russ Housley | [Ballot discuss] The time shifting attack concerns raised by Erik Nordmark need to be resolved. See the note from the Mobility Directorate in … [Ballot discuss] The time shifting attack concerns raised by Erik Nordmark need to be resolved. See the note from the Mobility Directorate in the Tracker comment history. |
2006-02-02
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Yes by Russ Housley |
2006-01-27
|
08 | Margaret Cullen | State Changes to IESG Evaluation from Approved-announcement to be sent::Point Raised - writeup needed by Margaret Wasserman |
2006-01-27
|
08 | Margaret Cullen | [Ballot discuss] A last minute issue was raised by Erik Nordmark in a Mobility Directorate review of this document. The issue is summarized in the … [Ballot discuss] A last minute issue was raised by Erik Nordmark in a Mobility Directorate review of this document. The issue is summarized in the two attached e-mail messages. I am not sure how/if this will be get resolved, but I am entering a discuss on this document to make sure that this issue is considered and addressed before the document goes forward. ==> Original review from Erik Nordmark: Margaret Wasserman wrote: > This week's IESG telechat agenda (for 1/19) includes > draft-ietf-mobike-protocol-07.txt which is being reviewed for Proposed > Standard. I went and looked at one aspect, and found the document silent on it. The issue is time-shifting attacks, and I think the document should at least mention them in the security considerations section, if not provide some way to limit their impact. But perhaps I've completely misunderstood how things should work, and somebody on mdir can correct my misunderstandings of the protocol. Let's take an example that illustrates my concern. A host is using some public-access network infrastructure. It gets allocated IP address B by a DHCP server. B contacts server A (www.example.com), and uses Mobike. As a result of this, A ends up with a combination of SPD and SADBs that make packets destined to IP address B be subject to the IPsec SA that was setup. Thus packets destined from A to B are placed on an ESP tunnel, with a destination of B. The host (B) later moves to a different network, where it is assigned IP address C. It uses Mobike to move the IKE and IPsec SAs from using B to using C. This (and here is were the document is silent) means that packets sent from A to B and placed in an ESP tunnel with a destination of C. (In any case, there isn't any text I could find that says that there is no residual IKE or IPsec SA or policy that refer to B.) What happens when another host appears on the initial public-access infrastructure and is assigned IP address B by the DHCP server? (This could be hours or days after the first host left.) When that host tries to contact www.example.com, things would fail due to the SADB and SPD entries that were created by the original host. What am I missing? Erik _______________________________________________ mdir mailing list mdir@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mdir ==> Later mdir list mail from Erik Nordmark to Henrik Levkowetz: On 2006-01-26 20:24 Erik Nordmark said the following: > Henrik Levkowetz wrote: > > >>Possibly, but as you point out, it won't work very well when you're >>moving the endpoint about ;-) > > > So we chartered Mobike to solve that problem, right? > > Or were they chartered to only solve the tunnel to SG problem? Without having been directly involved in the Mobike chartering, my understanding has been that it was limited to the tunnel to VPN GW scenario. >>Right, I agree. From the inception of Mobike I've seen it in a >>context of VPN GWs exclusively - clearly the document needs to express >>this limitation if it exists, or need to answer the point you bring up >>if the limitation should not exist. > > > If that is indeed the case, then I conclude the document is utterly > silent on this limited applicability. Which is clearly unfortunate. > How about renaming the specification from "IKEv2 Mobility and > Multihoming Protocol" to "IKEv2 Security Gateway Mobility and > Multihoming Protocol", and putting a fat note in the applicability > section to point out the actual assumptions in this area. > > Sure had me fooled that they were doing something more than a SG VPN > solution; the way I read the introductory part of the document it > talks about "only tunnel-mode" and almost pretends that it can be > extended to transport mode and SCTP support. I find that preposterous > given that the protocol can't even safely handle end-to-end tunnel mode. > > In any case, the document needs to talk about time shifting attacks, > even it is to clarify that the limitations to the SG scenario means > they can be handled. But the protocol might need to check that the > inner peer address and outer peer address are indeed different. Right. Henrik |
2006-01-27
|
08 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from No Objection by Margaret Wasserman |
2006-01-20
|
08 | (System) | Removed from agenda for telechat - 2006-01-19 |
2006-01-19
|
08 | Amy Vezza | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza |
2006-01-19
|
08 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by IESG Secretary |
2006-01-19
|
08 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2006-01-19
|
08 | Allison Mankin | [Ballot comment] Another capability for the Internet's multi-address architecture. This took a lot of care, and in a few hours read of a one week … [Ballot comment] Another capability for the Internet's multi-address architecture. This took a lot of care, and in a few hours read of a one week review, it looked sound. Sometime we should do strong survey from the user/application view. Are the multi-addressing capabilities coherent? And we should put applications/transports over these varied capabilities in simulators and ensure we aren't missing issues. |
2006-01-19
|
08 | Allison Mankin | [Ballot comment] Another capability for the Internet's multi-address architecture. This took a lot of care, and in a few hours read of a one week … [Ballot comment] Another capability for the Internet's multi-address architecture. This took a lot of care, and in a few hours read of a one week review, it looked sound. Sometime we should do strong survey from the user/application view. Are the multi-addressing capabilities coherent? And we should put applications/transports over these varied capabilities in simulators and ensure we aren't missing issues. |
2006-01-19
|
08 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2006-01-19
|
08 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2006-01-19
|
08 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2006-01-18
|
08 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2006-01-18
|
08 | Michelle Cotton | IANA Comments: Upon approval of this document the IANA will register the following: 2 Notify Messages - Error Types 8 Notify Messages - Status Types … IANA Comments: Upon approval of this document the IANA will register the following: 2 Notify Messages - Error Types 8 Notify Messages - Status Types These will be made in the IKEv2 notifications IKEv2 Notify Message Types registry found at: http://www.iana.org/assignments/ikev2-parameters |
2006-01-18
|
08 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2006-01-18
|
08 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
2006-01-18
|
08 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2006-01-18
|
08 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2006-01-17
|
08 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2006-01-17
|
08 | Brian Carpenter | [Ballot comment] Comments from Gen-ART review by Elwyn Davies: General: There is no discussion of how the Critical bit should be set in the various … [Ballot comment] Comments from Gen-ART review by Elwyn Davies: General: There is no discussion of how the Critical bit should be set in the various Notifications. s1.1, para 1: IKEv2 doesn't just create SAs for use with tunnel mode. s3.5: Might be good to say explicitly before this point that additional info is needed in the SA (presumably in the SAD) including pending_update flag and the additional addresses. s3.9: 'If the exchange initiator receives an UNEXPECTED_NAT_DETECTED notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several times, starting from a new IKE_SA_INIT request.' Do we have any advice on the value of several here? s3.12: Would it not be the case that the IPsec packets would fail validation against the SA database (i.e. the SPI wouldn't match with the addresses and verification would fail)? Or are there cases (null encryption/auth maybe) when more verification is needed? I wonder if this can be made more specific? Editorial: s1.1: Maybe should explain why only IKEv2 is considered. s1.1, para 1: Need a reference for IKEv2 here (now RFC4306). s2.1, para 5: s/common with the use/common to the use/ s2.2, title: ? s/Runs/Exchanges/ s2.2: This needs an explanation of the notation including a copy of the notation table from RFC4306 s1.2 and what is the meaning of N(...), plus the meaning of (IPx:4500 -> IPy:4500) etc. s2.2: I don't think the meaning of the braces pair {} in the packet exchanges is defined. s3.4: Maybe explicitly say ADDITIONAL_*_ADDRESS ::= ADDITIONAL_IPv4_ADDRESS | ADDITIONAL_IPv6_ADDRESS s3.6, Next to last para: Might be good to add the reason why the additional addresses are not needed, i.e., the same one as in parentheses at the end of the next para. |
2006-01-17
|
08 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2006-01-04
|
08 | Russ Housley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley |
2006-01-04
|
08 | Russ Housley | [Note]: 'Proto shepherd is Jari Arkko ' added by Russ Housley |
2006-01-04
|
08 | Russ Housley | Placed on agenda for telechat - 2006-01-19 by Russ Housley |
2006-01-04
|
08 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded for Russ Housley |
2006-01-04
|
08 | Russ Housley | Ballot has been issued by Russ Housley |
2006-01-04
|
08 | Russ Housley | Created "Approve" ballot |
2006-01-03
|
08 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2005-12-20
|
08 | Amy Vezza | Last call sent |
2005-12-20
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-12-20
|
08 | Russ Housley | Last Call was requested by Russ Housley |
2005-12-20
|
08 | Russ Housley | State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley |
2005-12-20
|
08 | (System) | Ballot writeup text was added |
2005-12-20
|
08 | (System) | Last call text was added |
2005-12-20
|
08 | (System) | Ballot approval text was added |
2005-12-20
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-12-20
|
07 | (System) | New version available: draft-ietf-mobike-protocol-07.txt |
2005-12-15
|
08 | Russ Housley | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley |
2005-12-15
|
08 | Russ Housley | AD Review comments provided on 15-Dec-2005. Most were editorial. However, I am concerned that there is no normative text about the update of the IPsec … AD Review comments provided on 15-Dec-2005. Most were editorial. However, I am concerned that there is no normative text about the update of the IPsec databases (like the SAD). The only guidance appears in Appendix A. Without some normative text on this subject, how will we get interoperable implementations? |
2005-12-15
|
08 | Russ Housley | State Changes to AD Evaluation from Publication Requested by Russ Housley |
2005-12-15
|
08 | Russ Housley | Draft Added by Russ Housley in state Publication Requested |
2005-11-16
|
06 | (System) | New version available: draft-ietf-mobike-protocol-06.txt |
2005-10-27
|
05 | (System) | New version available: draft-ietf-mobike-protocol-05.txt |
2005-10-07
|
04 | (System) | New version available: draft-ietf-mobike-protocol-04.txt |
2005-09-29
|
03 | (System) | New version available: draft-ietf-mobike-protocol-03.txt |
2005-09-12
|
02 | (System) | New version available: draft-ietf-mobike-protocol-02.txt |
2005-07-15
|
01 | (System) | New version available: draft-ietf-mobike-protocol-01.txt |
2005-06-29
|
00 | (System) | New version available: draft-ietf-mobike-protocol-00.txt |