[PATCH 0/7] P2PS fixes based on http://w1.fi/p/p2ps-pending/

[Peer, Ilan]

Hi Jouni,

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Monday, August 10, 2015 20:17
> To: Peer, Ilan
> Cc: hostap at lists.shmoo.com
> Subject: Re: [PATCH 0/7] P2PS fixes based on http://w1.fi/p/p2ps-pending/
> 
> On Sun, Aug 09, 2015 at 02:39:14PM +0000, Peer, Ilan wrote:
> > Using the intended P2P interface address exchanged in the P2PS PD for
> deducting the P2P Client interface address might be wrong, as from our
> interpretation of the spec, the P2P Interface address attribute is intend to
> convey the address of the P2P GO and not that of the P2P Client. In addition, it
> is possible that the P2P interface address exchanged in the PD signaling would
> not be used once the P2PS PD is done. For example, in the case that one of
> the devices publishes support for (Cli, GO) and adds the address of a currently
> running P2P GO, it is possible that at the end of the PD signaling it would
> instantiate another P2P Client, in which case a new P2P interface address
> would be used.
> 
> Could you please point me to the exact spec language that supports such
> interpretation? I don't see P2PS changing the definition of the Intended P2P
> Interface Address attribute: the P2P Interface Address a P2P Device intends
> to use in a P2P Group. This is an address on the device sending the attribute
> regardless of whether the device becomes a GO or P2P Client.
> 

Nothing in the spec changes the definition of the intended P2P interface address attribute. However, tables 14 and 15 specify when this attribute is required, and from them it can be deduced that it is only needed on the GO side. For example, consider the case where a seeker starts a P2PS PD specifying connection capability of P2P GO (where the attribute is added) and the advertiser replies with status success and connection capability of P2P Client. In this case the advertiser (about to be the P2P Client) does not include the intended P2P interface address attribute (as it is not required to).

> The original P2P definition most certainly expected the following group
> formation to use the indicated address and not something else just because
> the role "changed" in GO Negotiation. If P2PS changed that design, it is quite
> unfortunate. However, I did not find any clear statement in either spec
> indicating such a use case. I can only find P2PS spec listing rules on when this
> attribute is included; not indicating anything about it having different value
> than the P2P spec definition.
> 

The P2P definition (looking at version 1.5) requires the attribute in case of GoN request/response and describes the content of the attribute in these cases, but leaves this definition open in case of P2PS in addition to stating that it is optional in P2PS PD frames, thus creating cases that can result where the intended P2P GO does not know the intended P2P interface address of the P2P client (as the example above, and the pervious example).

Regards,

Ilan.