Re: Issue 59: Editorial comments from Tero (was: Comments of draft-ietf-mobike-protocol-04.txt)

Tero Kivinen wrote:
> 1)
> 
> In section 3.2. the second example should probably clarify that
> the exchange in step 3 is successful, i.e. the responder do
> respond to that in this example protocol run (as can be seen from
> the return packet sent by the responder, but the text below it
> gives feeling that it failed ("initiator gives up")).
>
> Perhaps there should also be example where that exchange is not
> successful.

Hmm... the example was written by Jari, but I suspect the intention
was that step 3 is not successful (the initiator doesn't receive a
reply -- but then step 4 is wrong, as the initiator has to continue
retransmitting the first request).

Jari, could you clarify?

<snip>

> 4)
> 
> The last sentence in the section 4.5 should say
> 
>     Similarly, a simple "VPN gateway" that has only a single
>     address, and is not going to change it, does not need to send
>     or process ADDITIONAL_*_ADDRESS notifications.
> 
> It needs to understand them so much it can ignore them.

Yes, but that's already required by IKEv2 ("Notify payloads 
with status types ... MUST be ignored if not recognized.").

<snip>

> 5)
> 
> In section 4.6 the paragraph:
> 
>    Any INFORMATIONAL exchange can be used for return routability
>    purposes, with one exception: when a valid response is
>    received, we know the other party can receive packets at the
>    claimed address.
>
> should probably tell what is the one exception... Or more exactly 
> what that paragraph is trying to tell us?

OK, I'll try to clarify that the exception here refers to
the last paragraph of 4.6.

> 6)
> 
> Perhaps the section 4.7 should also mention that DPD packets can
> also include UPDATE_SA_ADDRESSES in case the initiator suspects
> that the NAT mapping has changed, and that will save one round
> trip.

Hmm, yes, I had intended to include that already in -03, but
somehow that was forgotten. How about adding this to the 3rd
paragraph?

   If the initiator suspects that the NAT mapping has changed,  
   it MAY also skip the detection step and send UPDATE_SA_ADDRESSES 
   immediately. This saves one roundtrip if the NAT mapping 
   has indeed changed.   

<snip>

> 9) 
>
> I agree with the previous proposal that we should split those
> notifies to error and status notifies, and have separate section
> for each of those.

I'm wondering why?  To me it seems the only reader of this spec who
needs to know about the error/status distinction is IANA (and that's
already covered in the IANA considerations section)...

(But if there's a good reason to do it, maybe we could re-arrange
the subsections in Section 5 to, say, list those notifications
whose number comes from the status type range first.)

> 10)
> 
> The section 5.7 of the NO_NATS_ALLOWED could have a bit more 
> text explaining the exact data put in, i.e. something like
>
>	     Data = src-ip (4 or 16 bytes) | src-port (2 bytes) |
>	            dst-ip (4 or 16 bytes) | dst-port (2 bytes)
>
>      All data is stored in the network byte order without any
>      padding. The lenght of the data is 12 bytes for IPv4, and 36
>      bytes for the IPv6.

Ok, will be clarified with something along those lines.

> 11)
> 
> The section 6.1 should probably also mention that NO_NATS_ALLOWED
> might be used with IPv6 in general, where NATs are not (yet) used.

I think IPv6 implementations will often need to support NAT
traversal anyway, because UDP is more likely to get through
stateful firewalls than plain ESP... 

But yes, perhaps IPv6 could be mentioned there anyway.  How 
about rephrasing that to "This feature is mainly intendeed for 
IPv6 and site-to-site VPN cases, where..."?

> 12)
> 
> The section 6.5 should mention that those information is
> generally available only for the other peer, not to the passive
> listeners (it is encrypted). There is two (or one if we move the
> NO_NATS_ALLOWED) exceptions to the rule: NAT_DETECTION_*_IP
> packets of the IKE_SA_INIT and the NO_NATS_ALLOWED (if sent
> inside the IKE_SA_INIT). Those payloads having IP-address
> information is sent in clear.

How about adding this to the end of the 5th paragraph of 6.5:

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

NO_NATS_ALLOWED is a bit different: since it's used only when we 
know beforehand that there are no NATs, so it contains the same 
address as the IP header -- so encrypting it does not provide
anything extra...

Best regards,
Pasi