Subject: Re: [Mobike] Issue 46: Questions about additional addresses (was: Comments on draft-ietf-mobike-protocol-03.txt)

From: <[email-masked]>
Date: Mon, 3 Oct 2005 18:23:10 +0300

> >- Section 4.5
> >        - What is the use of "NO_ADDITIONAL_ADDRESS" 
> >          notification ? At least i did not see any 
> >          description/hint of how one would use it. 
>
> Missing text, I think. Section 4.5 or 5.3 should
> include something along the following lines:
> 
>    The ADDITIONAL_*_ADDRESS notification MUST be used
>    when there's more than one address to be communicated
>    to the peer. The NO_ADDITIONAL_ADDRESSES notification
>    MUST be used when there is only one address, and the peer
>    was previously informed of multiple addresses. As a result,
>    NO_ADDITIONAL_ADDRESSES notification is not needed
>    in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES
>    notification is needed in the the initial exchange only if there
>    is more than one address.

This is already described in Section 5.3, but I agree, the text
perhaps needs some clarification..

> >       - What is the use in adding NO_NATS_ALLOWED along with
> >       ADDITIONAL_ADDRESS notification ?  The receiver of
> >       ADDITIONAL_ADDRESS takes it from the notification payload
> >       and not from the IP header.  Is it just that you want to
> >       include NO_NATS_ALLOWED with all possible notifications ?
> >       But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA
> >       _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and
> >       UPDATE_SA, you take from the IP header and hence it makes
> >       sense. Why do we need it for ADDITIONAL_ADDRESS ?
>
> I can't answer this. Pasi?

Because just like in the IKE_SA_INIT case, the notifications
contain addresses _in_addition_ to the one used in the IP header.
So we need NO_NATS_ALLOWED to protect the one in the IP header.

(We could change it so that all the addresses were in
ADDITIONAL_*_ADDRESS notifications, but this way it's more 
uniform treatment IKE_SA_INIT vs. INFORMATIONAL, and NAT-T 
vs. NAT prohibition.)

> >       - The VPN gateway may have a single address but the client
> >       may have multiple addresses.  In that case it is okay if it
> >       does not send ADDITIONAL_ADDRESS notification but it needs
> >       to process one from the client. The last paragraph states
> >       something different.
>
> Agreed, this is an issue. I think we wanted to say that clients that
> do not intend to use more than one address do not have to send
> ADDITIONAL_*_ADDRESS notifications.  But they still need to be able
> to handle them. This is a part of the basic mobike protocol that
> devices supporting this rfc-to-be should support.

The text actually says that

  "a simple "VPN gateway" that has only a single address, and is
  not going to change it, does not need to send or understand
  ADDITIONAL_*_ADDRESS notifications.

This is correct: the responder in this case does not have to
understand ADDITIONAL_*_ADDRESS notifications because the only time 
it would use the information is when its own address changes.  Or
in other words, even if it did understand them, it would not make 
any difference since the information would not be used for anything.

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Oct 2005 20:28:45 +0300

>perhaps needs some clarification..
Ok. Use your judgment to edit this in. But I think
the current text on this point is vague.

>So we need NO_NATS_ALLOWED to protect the one in the IP header.
Hmm. Is that address used for something, beyond
responding to the request?

>any difference since the information would not be used for anything
>  
>
Ok. Now I understand. But you still had the other
part in the text that said:

   A minimal "mobile client" could have a policy
   that says that only the responder's address specified in local
   configuration is acceptable.

I can see that such a policy is possible.  But I'm not sure
I see the same initiator-decides effect here than was
present in the gateway side. Since the client is responsible
for address selection in both, it seems that a client
that does not implement gateway ADDITIONAL_*_ADDRESS
payloads does not implement the full protocol. We can of
course choose what our mandatory-to-implement requirements
are. Does the text above mean that a minimal mobile
client can choose not to implement this part of the protocol,
or only that its legal to configure it so that expects a single
address from the other side? I'd rather see the latter...

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 3 Oct 2005 20:21:42 -0700

> perhaps needs some clarification..
So, if i informed the peer about 5 addresses, and two of my addresses
became invalid,  what do i do then ? Why is returning to one valid
address case special ?

> So we need NO_NATS_ALLOWED to protect the one in the IP header.
Then, i should be able to use NO_NATS_ALLOWED in any message
to protect the IP header. Sorry, i still can't understand.

> any difference since the information would not be used for anything.
Hmm.. but it can still change the peer's address given in the ADDITIONAL_ADDRESS.
I understand that it does not have to change. But if the client has multiple
addresses and there is some connectivity problem, it can try a different address, right ?

-mohan

-mohan