Skip to main content

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