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

From: <[email-masked]>
Date: Thu, 20 Oct 2005 11:30:19 +0300

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:29:11 +0300

> the last paragraph of 4.6.

Ok, now I know what the exception is... I didn't know what the
exception was before, that was why I asked it there...
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:31:18 +0300

[trying to now answer via separate emails]

> with status types ... MUST be ignored if not recognized.").

Yes, but as we are working over IKEv2, we can also change some of the
requirements, just wanted to make sure that we are not going to lower
that restriction specified in the IKEv2 document here.  
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:31:55 +0300

>    immediately. This saves one roundtrip if the NAT mapping 

Sounds good.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:35:17 +0300

> whose number comes from the status type range first.)

Because as you said in the earlier, unknown status notifications are
ignored, and unknown error notifications cause request to fail
entirely. So there is difference for them in the processing point of
view too. Thats why it might be good idea to also keep them separate
in the documentation too.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:36:11 +0300

> IPv6 and site-to-site VPN cases, where..."?

That would be enough for me.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:40:04 +0300

> address as the IP header -- so encrypting it does not provide

I disagree with that. How can we know there is no NAT between
beforehand? We have not tested the path or anything, so we do not know
if there is NAT or not. We can hope there is no NAT, as if there is
one, then we cannot establish connection, but we cannot know anything
about presense of NATs.

Even if our configurations says there must not be NATs between us, it
does not mean that this is necessarely true, and it does not mean that
we can reveal the IP-addresses to the listeners.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Sat, 22 Oct 2005 20:04:17 +0300

>retransmitting the first request).
It was indeed intention that the return packet in step 3
would be lost. We forgot to draw this in the flow, however.
I have used something like

                                            REQ
                  ------------------------------------------------>
                                            RESP
                                 /----------------------------------

elsewhere. But the real question is I guess step 4
correctness. Yes, I actually thought that we could
switch to another request, but as you point out,
this is incorrect. Hmm... this means that we can't
piggyback the RR test/cookie2 all of a sudden. Oh
well, that means another roundtrip in this case.
Retransmit the step 3 packet to a different address,
then do an RR test separately.

--Jari