Subject: Re: [Mobike] 68 - minimal conformance requirements

From: <[email-masked]>
Date: Mon, 24 Oct 2005 12:52:44 +0300

Jari Arkko wrote:

> I checked issue #46 where we discussed this before.
> The conclusion appeared to be that for the gateway the
> current text is OK. On the client part I don't think we
> decided anything.
> 
> However, when thinking about this it seems that even
> the gateway part is suspect. It is true that you don't
> need the additional addresses on a gateway that is
> a responder. However, if this gateway is working in
> gateway-to-gateway mode and is an initiator towards
> the peer gateway which has multiple addresses, then
> we need it.
> 
> We could try to describe all this, but I think the cost
> of that is greater than simply saying that nodes that
> conform to this specification need to be able to understand
> the additional addresses. It is another matter what needs
> to be sent.

I think the problem can be fixed simply by changing "client"
to "initiator" and "gateway" to "responder".

> Here's a proposed text change:
> 
>    Note that both peers can have their own policies about what
>    addresses are acceptable to use.  A minimal "mobile client"
>    could have a policy that says that only the responder's
>    address specified in local configuration is acceptable.  This
>    kind of client does not have to send or process
>    ADDITIONAL_*_ADDRESS notifications.  Similarly, 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.
> 
> =>
> 
>    Note that a node that has only a single address at any given
>    time does not need to send ADDITIONAL_*_ADDRESS
>    notifications, but all nodes that support this specification
>    must understand the reception of such notifications. However,
>    nodes MAY have their own policies about what addresses are
>    acceptable to use.

IMHO this is even more confusing than the original text...  Having
a single address at any given time doesn't really have much to do
with this paragraph. Even if a node has several addresses, it does
not need to send ADDITIONAL_*_ADDRESS notifications if either

(1) it doesn't want to use those addresses for IPsec traffic, or
(2) the node is the initiator, and it does not want to use
any other responder addresses.

Furthermore, the responder does not have to understand
ADDITIONAL_*_ADDRESS notifications (beyond treating them like any
other unrecognized status notification; that is, ignoring them) 
if it's not going to change its address.

How about rephrasing this as follows?

    Note that both peers can have their own policies about what
    addresses are acceptable to use, and certain types of policies
    may simplify implementation. For instance, if the responder
    has a single fixed address, it does need to process
    ADDITIONAL_*_ADDRESS notifications it receives (beyond
    ignoring unrecognized status notifications as already required
    in [IKEv2]). Furthermore, if the initiator has a policy saying
    that only the responder address specified in local
    configuration is acceptable, it does not have to send its own
    additional addresses to the responder (since the responder
    does not need them except when changing its own address).

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Oct 2005 13:03:30 +0300

>any other responder addresses.
Yes.

>if it's not going to change its address.
Yes -- as long as we are talking about a "responder"
and not a "gateway".

>    does not need them except when changing its own address).
Works for me. Thanks.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 24 Oct 2005 22:27:13 -0700

>     in [IKEv2]). Furthermore, if the initiator has a policy saying

In section 4.5, it talks about how a responder can try a different
address for its peer. The responder itself has only one address
but it can try different peer addresses. Or Are you saying that
the policy says don't try different peer addresses ?

>     does not need them except when changing its own address).
This is still confusing to me :-)

-mohan