Re: Issue 59 (was: protocol draft status and moving forward)

Tero Kivinen wrote:
> 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:
>
<snip>
> Just to align with the format used in the IKEv2.

The need for a fifty-page clarifications document suggests that 
on editorial issues, we probably shouldn't align with IKEv2 
too closely :-)

But OK, I'll make this change so we get this issue closed...

> For 10 change:
<snip>
> 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.
> ----------------------------------------------------------------------

IMHO we shouldn't repeat exactly the same information twice.  Do you
think there's a danger than an implementors would misunderstand the
current text and get interop problems? (if yes, we should rewrite 
the text; if not, it's good enough and doesn't need polishing)

> For 11 change: (there is also some half-written sentence there 
> that I fixed at the same time)
<snip>
> 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 sub-issue 11, I already added a mention of IPv6 elsewhere.
E.g.  Section 3.9 says "This feature is mainly intended for IPv6 
and site-to-site VPN cases..."

Is mentioning IPv6 some more helpful for the reader..?

> For 12 change:
<snip>
>    Note, that this information is only available to the other peers,
>    not to the passive listeners of the traffic.

For sub-isuse 12, I already added this later in the same section:

   Furthermore, the ADDITIONAL_IP4/6_ADDRESS notifications are sent
   encrypted, so the addresses are not visible to eavesdroppers
   (unless, of course, they are later used for sending IKEv2/IPsec
   traffic).

Is that sufficient?

Best regards,
Pasi