Subject: Re: [Mobike] Issue 59 (was: protocol draft status and moving forward)

From: <[email-masked]>
Date: Fri, 28 Oct 2005 15:02:00 +0300

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 16:21:14 +0300

> on editorial issues, we probably shouldn't align with IKEv2 

True, but thats why I do want to add the text in this document, not on
the mobike-clarifications document. Thus lets put all the text here
please, and do not try to condence things that you think are not
needed (as we later will notice that people will misunderstand those
and we need clarifications document). 

> the text; if not, it's good enough and doesn't need polishing)

Yes. People WILL misunderstand any text you put there.

If you do not want to add the text twice, then add the picture, not
the text. Text is hard to parse when you are trying to implement
things, and then you end up interpreting every hidden meaning before
each word used.

There was several missinterpretations of the IKEv2 section 2.15 which
do not have picture what is signed in the auth payload, but just text
explaining that. This was clarified in the section 3.1 of the
clarifiation draft. 

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

Yes. I think it should be repeated also in the security considerations
section, just to tell where this protection can be used. 

>    (unless, of course, they are later used for sending IKEv2/IPsec

Hmm.... I would like it to be mentioned in the first paragraph, as it
will clearly identify the problem to the reader immediately, so he can
skip the whole section if that does not apply to him, but I think it
could be enough to have it there where it is now.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike