Subject: Re: [pcp] UNSUPP_FAMILY error code

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 11 Jun 2013 13:04:32 +0000

Hi Stuart,

Are you planning on updating the draft with this discussion of EI -
FAMILY- Mappings and internal port considerations?

Thanks,

Reinaldo

On 5/30/13 2:05 PM, "Simon Perreault" <[email-masked]> wrote:

>Le 2013-05-30 18:30, Stuart Cheshire a écrit :
>> On 30 May 2013, at 9:25, Simon Perreault wrote:
>>
>>> - What would happen if a network-specific NAT64 prefix is used? How
>>>can the PCP client know what will happen (NAT64 or NAT66) to packets it
>>>sends if it doesn't know about that prefix?
>>>
>>> - What would happen in the NAT44 + NAT46 example we've been
>>>discussing? There is no well-known prefix to help disambiguate.
>>>
>>> Note that I'm not considering only replies to connections initiated
>>>from the outside. I'm also interested in connections initiated from the
>>>inside, which MAP also covers.
>>
>> I agree that outbound connections (and packets) need to work.
>>
>> I don't think the client needs to know what will happen. But the
>>gateway does know. If the destination is a "real" address then the
>>packet is sent to that address. If the destination address belongs to
>>the address-family-translating gateway's address pool, then the gateway
>>MUST translate it to the other address family, because the destination
>>is not a "real" address and will go nowhere useful if sent as-is.
>
>Hmmm... I started replying to this with a counter-example where the
>client *needs* to know what will happen, but I could not make it work.
>What you're saying seems correct. I need to sleep on this.
>
>Now, the second and somewhat less important reason that mappings cannot
>share the same internal port is that, as the RFC is currently written,
>two matchings do not involve the external address.
>
>a) Servers match requests against existing mappings on the internal
>address + port. This happens before the suggested external address field
>is inspected. Section "11.3. Processing a MAP Request":
>
>    If the internal port, protocol, and internal address match an
>    existing static mapping (which will have no nonce), then a PCP reply
>    is sent giving the external address and port of that static mapping,
>    using the nonce from the PCP request.  The server does not record the
>    nonce.
>
>    [...]
>
>    It is possible that a mapping might already exist for a requested
>    internal address, protocol, and port.  If so, the PCP server takes
>    the following actions:
>
>    [...]
>
>    If no mapping exists for the internal address, protocol, and port,
>    and the PCP server is able to create a mapping using the suggested
>    external address and port, it SHOULD do so.
>
>b) Clients match responses with requests on the internal address + port.
>Section "11.4. Processing a MAP Response":
>
>    After performing common PCP response processing, the response is
>    further matched with a previously sent MAP request by comparing the
>    internal IP address (the destination IP address of the PCP response,
>    or other IP address specified via the THIRD_PARTY option), the
>    protocol, the internal port, and the mapping nonce.  Other fields are
>    not compared, because the PCP server sets those fields.
>
>Could these two things be updated in your draft? We would need to say
>basically that the suggested external address family is also part of the
>match tuple in both cases. There would be two consequences to that:
>
>- The client would now be expected to set the suggested external address
>family correctly in refresh requests.
>
>- The server could not reply with an external address family different
>from the one contained in the request.
>
>
>Thanks all for the frenetic exchange!
>
>Simon
>-- 
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Jun 2013 21:44:52 -0700

> FAMILY- Mappings and internal port considerations?

Done: <http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-02>

Stuart Cheshire

---

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Jun 2013 12:31:31 +0200

> Done: <http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-02>

Good job!

Still missing is the nonce check thing. Here's some text as a contribution:

X. New Nonce Check Behavior

A server verifies the nonce in a MAP or PEER request as described in 
Sections 11.3 and 12.3 of [RFC6887]. In a nutshell, the server returns 
NOT_AUTHORIZED when the nonce check fails for a refresh request.

This behavior is problematic for two reasons:

- It makes PCP less useful by preventing its use for explicitly 
conveying information about an existing mapping while this information 
can be discovered by implicit means. For example, traffic could be sent 
to a destination controlled by the client to discover the applicable 
mapping's external address. Furthermore, the mapping's lifetime could be 
discovered heuristically by sending such probe traffic at regular interval.

- It makes PCP behave differently for explicit dynamic versus other 
kinds of mappings. Indeed, requests matching static mappings are not 
subjected to the nonce check and will result in a response containing 
the static mapping's current state. There is no reason that MAP requests 
matching a dynamic mapping should return less information.

Therefore, the following new nonce check behaviour MUST be implemented 
instead:

X.1. Nonce Check for MAP Requests

If operating in the Simple Threat Model (Section 18.1 of [RFC6887]), and 
the internal port, protocol, internal address, and external address 
family match an existing explicit dynamic mapping, but the mapping nonce 
does not match, a PCP reply is sent giving the external address, 
external port, and remaining lifetime of the mapping, using the nonce 
from the PCP request. The existing mapping and its nonce MUST NOT be 
modified. This specification makes no statement about mapping nonce with 
the Advanced Threat Model.

X.2. Nonce Check for PEER Requests

If operating in the Simple Threat Model (Section 18.1 of [RFC6887]), and 
the internal port, protocol, internal address, and external address 
family match a mapping that already exists, but the mapping nonce does 
not match (that is, a previous PEER request was processed), a PCP reply 
is sent giving the external address, external port, and remaining 
lifetime of the mapping using the nonce from the PCP request. The 
existing mapping and its nonce MUST NOT be modified. This specification 
makes no statement about mapping nonce with the Advanced Threat Model.

In summary, the only remaining circumstance where NOT_AUTHORIZED is to 
be returned, as described in Section 15.1 of [RFC6887], is when a PCP 
client attemps to delete a static mapping (i.e., a mapping created 
outside of PCP itself) or an outbound (implicit or PEER-created) mapping.

Simon

---

From: <[email-masked]>
Date: Wed, 12 Jun 2013 13:05:00 +0200

IMHO, the nonce text can be included in http://datatracker.ietf.org/doc/draft-boucadair-pcp-failure/ which identified already this issue. 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Simon
>Perreault
>Envoyé : mercredi 12 juin 2013 12:32
>À : Stuart Cheshire
>Cc : [email-masked]
>Objet : Re: [pcp] UNSUPP_FAMILY error code
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Jun 2013 13:10:49 +0200

> IMHO, the nonce text can be included in http://datatracker.ietf.org/doc/draft-boucadair-pcp-failure/ which identified already this issue.

I'd prefer to keep pcp-failure informational and concentrate all updates 
to 6887 in a single small draft.

Simon

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 12 Jun 2013 12:07:30 +0000

Right, this kind of update needs to be on a standards track document.

On 6/12/13 8:10 AM, "Simon Perreault" <[email-masked]> wrote:

>> IMHO, the nonce text can be included in
>>http://datatracker.ietf.org/doc/draft-boucadair-pcp-failure/ which
>>identified already this issue.
>

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Jun 2013 23:34:32 -0700

On 12 Jun 2013, at 3:31, Simon Perreault wrote:

> Still missing is the nonce check thing. Here's some text as a contribution...

Thanks.

I have submitted <http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-03> to add the changes to nonce checking rules.

Stuart Cheshire

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Jun 2013 11:25:00 +0200

> I have submitted <http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-03> to add the changes to nonce checking rules.

Did you intentionally change the text describing the new behaviour? 
Sections 3.1 and 3.2 now say that the nonce and lifetime are updated. 
That's completely different from the thread consensus (return the 
request's nonce and remaining lifetime), and certainly different from 
what I wrote.

Simon