RE: FW: external mobike-protocol-02 review (editorial) (issue 43)

Thanks for catching these... they are now filed as issue 43,
and I will take them into account in version -03.

Best regards,
Pasi

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On
> Behalf Of ext Jari Arkko
> Sent: Monday, September 19, 2005 9:13 AM
> To: MOBIKE Mailing List
> Cc: Pekka Savola
> Subject: [Mobike] FW: external mobike-protocol-02 review (editorial)
> 
> 
> (The editorial comments part)
> 
> ---------- Forwarded message ----------
> Date: Fri, 16 Sep 2005 14:22:53 +0300 (EEST)
> From: Pekka Savola <[email protected]>
> To: [email protected]
> Subject: external mobike-protocol-02 review
> 
> editorial
> ---------
> 
>    The initiator uses the set of responder addresses as an 
> input to its
>    address selection policy; it may at some later point decide to move
>    the IPsec traffic to one of these addresses using the procedure
>    described in Section 2.3.  The responder normally does not use the
>    set of initiator addresses for anything: the addresses are 
> used only
>    when the responder's own addresses change.
> 
> ==> the last sentence needs a forward reference (Section 2.3.4 in my
> proposal).
> 
> Such information itself MUST NOT be used to conclude than
>    an update is needed: instead, the initiator SHOULD trigger 
> dead peer
>    detection.
> 
> ==> I suggest adding explicit ref to DPD, especially when written in
> all-lowercase.
> 
>    The description in the rest of this section assumes that the
>    initiator has already decided what the new addresses 
> should be.  When
>    this decision has been made, the initiator
> 
>    o  Updates the IKE_SA and the IPsec SAs associated with this IKE_SA
>       with the new addresses, and sets the "pending_update" 
> flag in the
>       IKE_SA.
> 
> ==> s/initiator/initiator:/ (and similar elsewhere)
> ==> personally, I might have just repeated the "initiator" in 
> each bullet,
> but this is correct as well.
> 
>   o  When the window size allows, sends an INFORMATIONAL request
>       containing the UPDATE_SA_ADDRESSES notification payload (which
>       does not contain any data), and clears the 
> "pending_update" flag.
> 
>       Initiator                  Responder
>      -----------                -----------
>       HDR, SK { N(UPDATE_SA_ADDRESSES),
>                 [N(NAT_DETECTION_*_IP)],
>                 [N(NO_NATS_ALLOWED)],
>                 [N(COOKIE2)] } -->
> 
> ==> s/flag/flag, for example as follows:/ (or something like..)
> 
>                             <--  HDR, SK { [N(NAT_DETECTION_*_IP)],
>                                            [N(COOKIE2)],  }
> ==> s/COOKIE2)],/COOKIE2)]/
> 
>   MOBIKE payload relating to updating addresses are encrypted,
>    integrity protected, and replay protected using the IKE_SA.
> 
> ==> s/are/is/ or s/payload/payloads/
> 
>    However, security associations originally created for the 
> protection
>    of a specific flow between specific addresses may be moved through
>    MOBIKE.
> 
> ==> "moved" seems a bit odd choice for a word here?
> 
>    to use MOBIKE are configured in a manner that takes into 
> account that
>    a single security association can be used through 
> different paths at
>    different times.
> 
> ==> maybe s/paths/paths of varying security properties/ to 
> spell it out
> loud again
> 
>    reply is received, MOBIKE will usually consider the path working;if
> 
> ==> s/;/; /
> 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>