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

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

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). 

> > ----------------------------------------------------------------------
> > 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)

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. 

> > 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..?

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

> > 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?

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 protected]