Subject: [Mobike] protocol draft status and moving forward

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Oct 2005 15:39:59 +0300

We now have a new draft version 05 available (see links [1]
and [2]). Pasi worked hard on the edits, and there was good
discussion on the list. But we did not quite get all issues
resolved in time for the I-D deadline. Therefore, the plan
is to produce version 06 just before IETF and submit it
for AD review and IESG either during or right after the
meeting.

At this time I'd like to call some issues closed and
invite (a) further discussion on the remaining issues
so that we can get them resolved and (b) review that
your issues have been correctly resolved in -05. We
are very close to getting everything agreed on, so
we're setting a new deadline on Wednesday 2nd Nov
(next week) to complete all discussion about the
resolutions of issues raised in WGLC.

The issue list is at [3]. The issues that I believe still
need further discussion are

     68 - minimal conformance requirements
     60 - addresses in ike sa_init/auth
     56 - ingress filtering
     51 - spi collisions
     46 - question about additional addresses
     45 - clarifications on security considerations

These also need editing:

     64 - stephane's editorial issues (just needs editing?)
     58 - deleting an address (just needs editing, we're not reopening old issue)
     54 - marcelo's editorial comments
     52 - security of address updates

The closed issues are as follows. (Of course, these would
benefit from their submitters checking correct
implementation in -05.)

     69 - rr requirements
     67 - certain vs. possible changed address info
     66 - imprecise explanation of what nat cases are not supported
     65 - jari's editorial issues
     63 - extensibility and payload
     62 - editorial comments from francis
     61 - version number, again
     59 - tero's editorial comments (Tero - please check -05)
     57 - question about initiator decides (I think the feeling
          was that nothing will be added to the protocol document,
          but Pasi's list marked this as open. Pasi?)
     55 - mobike scope and limitations (Everyone - please check -05;
          Pasi I think you mark this as closed because people were 
          agreeing to the text)
     53 - editorial comments from pete
     50 - more editorial comments from maureen
     47 - more comments from mohan (Mohan - please check -05)
     49 - editorial comments from maureen
     48 - editorial comments from james
     44 - nat changes and ike rekey (Pasi I think people were
          agreeing to the text)

Let us know if something was misclassified above...

Pointers:

[1] http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-05.txt
[2] http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-05-from-04.html
[3] http://www.vpnc.org/ietf-mobike/issues.html 
<http://www.vpnc.org/ietf-mobike/issues.html>

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Oct 2005 10:24:48 -0700

At 3:39 PM +0300 10/26/05, Jari Arkko wrote:
>Therefore, the plan

Just to be clear, the order of the coming steps are:

1) The editor produces -06.

2) The WG chairs ask the WG for a sanity check (no need to do another 
formal WG last call).

3) The WG chairs pass the draft to the AD with a statement about the consensus.

4) The AD considers the document. If he has concerns, he brings them 
back to the WG, and the WG either answers his concerns in a message 
or the editors fix the concerns with a new draft. Loop back to step 3.

5) The AD asks for an IETF-wide last call, which lasts two weeks.

6) If the IETF-wide last call brings up issues, the WG deals with 
them, and possibly a new draft is issued.

7) The IESG starts its review.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 10:54:05 +0300

>      59 - tero's editorial comments (Tero - please check -05)

Checking...

Hmm... 1, 4, 5, 6 seems to be in the draft.

9 is missing, and 10 is missing the picture.

11 and 12 seems also be missing.

Here is actual changes needed to be made to 05:

Change
----------------------------------------------------------------------
   4.  Payload Formats  . . . . . . . . . . . . . . . . . . . . . . . 20
     4.1.  MOBIKE_SUPPORTED Notify Payload  . . . . . . . . . . . . . 20
     4.2.  ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20
     4.3.  NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20
     4.4.  UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20
     4.5.  UNACCEPTABLE_ADDRESSES Notify Payload  . . . . . . . . . . 21
     4.6.  COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21
     4.7.  NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21
     4.8.  UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21
----------------------------------------------------------------------
to
----------------------------------------------------------------------
   4.  Payload Formats
     4.1   Notify messages - Error types
       4.1.1  UNACCEPTABLE_ADDRESSES Notify Payload
       4.1.2  UNEXPECTED_NAT_DETECTED Notify Payload
     4.2  Notify messages - Status types
       4.2.1.  MOBIKE_SUPPORTED Notify Payload
       4.2.2.  ADDITIONAL_IP4/6_ADDRESS Notify Payloads
       4.2.3.  NO_ADDITIONAL_ADDRESSES Notify Payload
       4.2.4.  UPDATE_SA_ADDRESSES Notify Payload
       4.2.5.  COOKIE2 Notify Payload
       4.2.6.  NO_NATS_ALLOWED Notify Payload
----------------------------------------------------------------------

And change the section
----------------------------------------------------------------------
4.  Payload Formats

   This specification defines several new IKEv2 Notify payload types.
   The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications
   are "error types"; the other notifications are "status types".  See
   [IKEv2] Section 3.10 for a general description of the Notify payload.
----------------------------------------------------------------------
to:
----------------------------------------------------------------------
4.  Payload Formats

   This specification defines several new IKEv2 Notify payload types.
   See [IKEv2] Section 3.10 for a general description of the Notify
   payload.

4.1  Notify messages - Error types

4.1.1  UNACCEPTABLE_ADDRESSES Notify Payload

...

4.2  Notify messages - Status types

...
----------------------------------------------------------------------

Also change the section 6. IANA Considerations from:
----------------------------------------------------------------------
      Notify Message               Value
      ---------------------------  -----
      MOBIKE_SUPPORTED             TBD-BY-IANA1 (16396..40959)
      ADDITIONAL_IP4_ADDRESS       TBD-BY-IANA2 (16396..40959)
      ADDITIONAL_IP6_ADDRESS       TBD-BY-IANA3 (16396..40959)
      NO_ADDITIONAL_ADDRESSES      TBD-BY-IANA4 (16396..40959)
      UPDATE_SA_ADDRESSES          TBD-BY-IANA5 (16396..40959)
      UNACCEPTABLE_ADDRESSES       TBD-BY-IANA6 (40..8191)
      COOKIE2                      TBD-BY-IANA7 (16396..40959)
      NO_NATS_ALLOWED              TBD-BY-IANA8 (16396..40959)
      UNEXPECTED_NAT_DETECTED      TBD-BY-IANA9 (40..8191)
----------------------------------------------------------------------

to

----------------------------------------------------------------------
      NOTIFY MESSAGES - ERROR TYPES      Value
      ------------------------------     -----
      UNACCEPTABLE_ADDRESSES       	 TBD-BY-IANA6 (40..8191)
      UNEXPECTED_NAT_DETECTED      	 TBD-BY-IANA9 (40..8191)

      NOTIFY MESSAGES - STATUS TYPES     Value
      ------------------------------     -----
      MOBIKE_SUPPORTED             	 TBD-BY-IANA1 (16396..40959)
      ADDITIONAL_IP4_ADDRESS       	 TBD-BY-IANA2 (16396..40959)
      ADDITIONAL_IP6_ADDRESS       	 TBD-BY-IANA3 (16396..40959)
      NO_ADDITIONAL_ADDRESSES      	 TBD-BY-IANA4 (16396..40959)
      UPDATE_SA_ADDRESSES          	 TBD-BY-IANA5 (16396..40959)
      COOKIE2                      	 TBD-BY-IANA7 (16396..40959)
      NO_NATS_ALLOWED              	 TBD-BY-IANA8 (16396..40959)
----------------------------------------------------------------------

Just to align with the format used in the IKEv2.

For 10 change:
----------------------------------------------------------------------
4.7.  NO_NATS_ALLOWED Notify Payload

   See Section 3.9 for a description of this notification.

   The data field of this notification contains the following
   information: the IP address from which the packet was sent (4 or 16
   bytes), the port from which the packet was sent (2 bytes, network
   byte order), the IP addresss to which the packet was sent (4 or 16
   bytes), and the port to which the packet was sent (2 bytes, network
   byte order).  The total length of the data field is thus 12 bytes for
   IPv4 and 36 bytes for IPv6.  The Notify Message Type for this message
   is TBD-BY-IANA8.  The Protocol ID and SPI Size fields are set to
   zero.
----------------------------------------------------------------------

to (just added the picture)
----------------------------------------------------------------------
4.7.  NO_NATS_ALLOWED Notify Payload

   See Section 3.9 for a description of this notification.

   The data field of this notification contains the following
   information: the IP address from which the packet was sent (4 or 16
   bytes), the port from which the packet was sent (2 bytes, network
   byte order), the IP addresss to which the packet was sent (4 or 16
   bytes), and the port to which the packet was sent (2 bytes, network
   byte order).  The total length of the data field is thus 12 bytes for
   IPv4 and 36 bytes for IPv6.

	Data = src-ip (4 or 16 bytes) | src-port (2 bytes) |
	       dst-ip (4 or 16 bytes) | dst-port (2 bytes)

   The Notify Message Type for this message is TBD-BY-IANA8. The
   Protocol ID and SPI Size fields are set to zero.
----------------------------------------------------------------------

For 11 change: (there is also some half-written sentence there that I
fixed at the same time)
----------------------------------------------------------------------
   MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
   detect modification, by outsiders, of the addresses in the IP header.
   Such modifications can only be performed by attackers who are on the
   path and capable of modifying the When this notification is used,
   communication through NATs and other address translators is
   impossible, so it is sent only when not doing NAT Traversal.
----------------------------------------------------------------------

to

----------------------------------------------------------------------
   MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
   detect modification, by outsiders, of the addresses in the IP
   header. When this notification is used, communication through NATs
   and other address translators is impossible, so it is sent only
   when not doing NAT Traversal. One of the main uses for this feature
   is the IPv6 networks.
----------------------------------------------------------------------

For 12 change:
----------------------------------------------------------------------
   MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications
   reveal information about which networks the peers are connected to.
----------------------------------------------------------------------

to

----------------------------------------------------------------------
   MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications
   reveal information about which networks the peers are connected to.
   Note, that this information is only available to the other peers,
   not to the passive listeners of the traffic.
----------------------------------------------------------------------
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 12:04:25 +0300

> need further discussion are

Actually I think the design draft should have enough text about this
(see section 5.1.2. Connectivity).

I do not think we need more than what is now in the protocol draft
already i.e:

----------------------------------------------------------------------
   MOBIKE follows the IKEv2 practice where a response message is sent to
   the same address and port from which the request was received.  This
   implies that MOBIKE does not work over unidirectional paths.
----------------------------------------------------------------------

but I would change that to:

----------------------------------------------------------------------
   MOBIKE follows the IKEv2 practice where a response message is sent to
   the same address and port from which the request was received.  This
   implies that MOBIKE does not work over unidirectional address
   pairs.
----------------------------------------------------------------------

i.e change "unidirectional paths" to "unidirectional address pairs",
as we do not really care about paths but address pairs.

MOBIKE will work perfectly if even if there is 2 unidirectional paths
(if we use the definition of path that includes the route of the
packet), which form one bidirectional address pair for MOBIKE to
use...
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 12:10:50 +0300

>      46 - question about additional addresses

There are some changes still missing from the 05 for this.

The beginning of the 3.6 would need to be changed, i.e. change

----------------------------------------------------------------------
   As described in Section 3.4, both the initiator and responder can
   send a list of additional addresses in the IKE_AUTH exchange.  This
   information can be updated by sending an INFORMATIONAL exchange
   request message that contains either one or more ADDITIONAL_IP4/
   6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.
   The message exchange will look as follows:
----------------------------------------------------------------------

to

----------------------------------------------------------------------
   As described in Section 3.4, both the initiator and responder can
   send a list of additional addresses in the IKE_AUTH exchange.  This
   information can be updated by sending an INFORMATIONAL exchange
   request message that contains either one or more ADDITIONAL_IP4/
   6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES
   notification. The NO_ADDITIONAL_ADDRESSES notify is used to
   indicate that there are no additional addresses besides the address
   used in the IP-headers. The ADDITIONAL_IP4/6_ADDRESS are used to
   give complete list of additional addresses (in addition to the one
   in the IP-header). The new address list will completely overwrite
   the previous list.

   The message exchange will look as follows:
----------------------------------------------------------------------
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2005 11:35:40 +0200

In your previous mail you wrote:

=> in fact this is more a requirement than a practice...

[email-masked]

PS: I am okay for the proposed change.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 28 Oct 2005 10:38:32 -0700 (PDT)

>    used in the IP-headers. The

Why does one have to indicate that they have
NO_ADDITIONAL_ADDRESSES ? If i don't send
ADDITIONAL_IP* notification then you just have one
address to operate with. What is the use of explicitly
indicating this ? Also, ADDITIONAL_IP with zero
address can do the same i guess i.e ADDITIONAL_IP*
replaces the previous list with zero or more
addresses.

-thanks
mohan

> ADDITIONAL_IP4/6_ADDRESS are used to

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Oct 2005 11:56:06 +0200

> replaces the previous list with zero or more

Ok, lets add explination about that too:

    The NO_ADDITIONAL_ADDRESSES notify is needed, as otherwise it
    would not be possible to distinguish empty DPD message from
    address update message that does not have any additional
    addresses. Now we can distinguish them, as DPD is empty
    INFORMATIONAL exchange and address update with no extra addresses
    is INFORMATIONAL exchange having only N(NO_ADDITIONAL_ADDRESSES).
    Both of them can have other additional payloads like N(COOKIE2)
    etc.  
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike