Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt

From: Alain Durand <[email-masked]>
Date: Wed, 1 Jun 2011 09:08:57 -0700

On May 31, 2011, at 2:40 PM, Dan Wing wrote:
> 
> 
>> - UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS could be removed, and replaced
>> with NOT_AUTHORIZED (more on that inline).
>> 
>> - There is no discussion about levels of conformance.  There's some
>> discussion about particular options being optional (e.g. THIRD_PARTY
>> not supported in certain deployment scenarios), but no overall
>> statement of what features must be supported by all conformant
>> implementations.  e.g. If I had a small embedded server that supported
>> MAP opcodes but not PEER, would it be conformant?
> 
> Nobody has initiated discussion or provided a straw-man on conformance
> levels.  What do we want?  Myself, if there is any chance of a wireless
> devices (which is approximately 100% chance), PEER needs to be supported
> because it allows the wireless device to optimize its NAT keepalive
> traffic.  But, to me, MAP doesn't need to necessarily be supported.

I think we should stay away from conformance levels. This gets very complex, very quickly,
and does not help interoperability.
The argument that MAP or PEER are only useful in a wireline or wireless scenario seams a bit weak to me.
We are now seeing fixed wireless environment... Which profile should they have?

I believe that unless there is a very strong reason against against, we should keep MAP & PEER functionality.

  - Alain.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jun 2011 20:02:15 +0000

Some comments on -12 are in the marked up copy at
http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base-12.pdf

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Friday, May 20, 2011 1:18 PM
To: [email-masked]
Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt

This message starts a two-week WGLC on
http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt

This last call will conclude on June 3rd at 5pm EST.

Please send your comments to the list.

We are scheduling a WebEx call shortly after the WGLC concludes,
and will send out details in separate email.

Thanks,
-Dave and Alain

---

From: Tina Tsou <[email-masked]>
Date: Fri, 03 Jun 2011 22:26:07 -0700

Dear all,
In section7, there is one description:
"It is REQUIRED that the PCP-controlled device assign the same
   external IP address to PCP-created explicit dynamic mappings and to
   implicit dynamic mappings."
It is only a requirement to CGN, but some existing CGN may not support this
requirement as defined in RFC4787-[REQ1]:
"Some NATs use the external IP address mapping in an arbitrary fashion
   (i.e., randomly): one internal IP address could have multiple
   external IP address mappings active at the same time for different
   sessions"
Therefore, I suggest the PCP client should also support this requirement
which was actually defined in 00 version but deleted in later versions
(maybe I missed the reason of the text change):
If there is any existing PCP mapping, PCP client should only request the
same external IP address as the one of those existing mappings. The reason
is that it will allow applications that use multiple ports originating from
the same internal IP address to also have the same external IP address.

Have a good weekend.
 
We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Thaler
Sent: Friday, June 03, 2011 1:02 PM
To: [email-masked]
Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt

-Dave
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Thaler
Sent: Friday, May 20, 2011 1:18 PM
To: [email-masked]
Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt

 

Thanks,
-Dave and Alain

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 4 Jun 2011 17:49:25 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tina Tsou
> Sent: Friday, June 03, 2011 10:26 PM
> To: 'Dave Thaler'; [email-masked]
> It is only a requirement to CGN, but some existing CGN may not support
> this requirement as defined in RFC4787-[REQ1]:

You quoted non-normative text; later in that same section of RFC4787
it explains how random ("Arbitrary") assignment causes harm.  REQ-2
says that "paired" is RECOMMENDED.

> Therefore, I suggest the PCP client should also support this
> requirement which was actually defined in 00 version but deleted in
> later versions (maybe I missed the reason of the text change):
> If there is any existing PCP mapping, PCP client should only request
> the same external IP address as the one of those existing mappings. The
> reason is that it will allow applications that use multiple ports
> originating from the same internal IP address to also have the same
> external IP address.

We (the NAT and PCP server) can't know if, when there is an implicit
dynamic connection from a host's source port, that connection was
done by the same application as the explicit mapping, or if the OS
happened to assign that source port to some other (unrelated) 
application.

If the NAT is EIM, it will reuse the same mapping it already 
has.  Because that is the definition of being a EIM NAT.  
And it is important that all implicit dynamic mappings use the
same public IPv4 address (for all the reasons stated in the
existing UDP and TCP RFCs).  We don't want PCP to make that
situation worse because some other un-related application did
a MAP request.

If it is a non-EIM NAT, I suppose there is a way to use separate
pools, if the non-EIM NAT applies some sort of logic to the 
implicit sessions -- the logic described in #2 of 
http://tools.ietf.org/html/draft-ietf-pcp-base-12#section-11.1
If you want/need that, please provide text.

But I fear the interaction that is created if non-EIM NAT
could create mappings on arbitrary IP addresses while EIM
NAT creates mappings on the same IP address.  For example,
if an application was tested with an EIM NAT (which always
assigns PCP-created mappings and implicit mappings to the
same external IP address), that application may well fail
when deployed behind a non-EIM NAT that (a) allocates different
IP addresses for different PCP mappings or (b) different IP
addresses for PCP mappings versus implicit dynamic mappings.

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 06 Jun 2011 22:07:42 -0700

My comments are below. I have text in mind to fix these things, but I haven't had time to write it up yet.

1. The definition of "subscriber" needs to be tightened up.

2. Why are some IP address fields "always 128 bits", and others are "32 or 128 bits"? Can we make this consistent?

3. Where a 128-bit IP address field contains an IPv4 address, we need to ensure that it can't inadvertently look like a valid IPv6 address as well as being a zero-padded IPv4 address.

4. Handling of the "O" bit is not fully specified for clients.

5. The THIRD_PARTY scenarios are a bit confused and self-contradictory.

6. Security for the THIRD_PARTY option needs more detailed specification.

7. PROCESSING_ERROR is unused.

8. ADDRESS_MISMATCH value is undefined.

9. How to handle responses from multiple PCP servers is underspecified. Responses don't arrive simultaneously. One arrives first, and then the other arrives later. What should the client do when the later one arrives? Undo everything it did in response to the first one?

10. Document uses both "NAT" and "NAPT". We should pick one and be consistent.

11. Use of wildcard ("0") address, port and protocol fields could be explained more clearly.

12. Don't match External_AF when validating response.

13. Is option length in bytes or 32-bit words?

14. Is FILTER Option mandatory to implement? How many filters per mapping?

15. Non-EIM seems like a confusing double negative ("non-independent"). Can we just say "EDM" ("dependent") instead?

16. Saying that an "Ethernet switch needs to perform ingress filtering" seems to be putting unreasonable demands on devices that know nothing about PCP, NAT, or even IP.

17. Why are new OpCodes "Standards Action" but new Result Codes are only "Specification Required"?

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Tina Tsou <[email-masked]>
Date: Tue, 07 Jun 2011 11:17:14 -0700

Dan,
Comments are in line beginning with [Tina: ...].

Best Regards,
Tina TSOU

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Saturday, June 04, 2011 5:49 PM
To: 'Tina Tsou'; 'Dave Thaler'; [email-masked]
Subject: RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt

We (the NAT and PCP server) can't know if, when there is an implicit
dynamic connection from a host's source port, that connection was
done by the same application as the explicit mapping, or if the OS
happened to assign that source port to some other (unrelated) 
application.
[Tina: If the connection was done by one application as the explicit
mapping, e.g., PCP mapping, the subsequent connection from the same internal
IP address will use the same external IP address according to the PCP
mapping. The implicit mapping will not match in this case. If the connection
was done by one application as the implicit mapping, the subsequent
connection can also use the same external IP address because the application
can make the PCP client to meet the same requirement.]

If it is a non-EIM NAT, I suppose there is a way to use separate
pools, if the non-EIM NAT applies some sort of logic to the 
implicit sessions -- the logic described in #2 of 
http://tools.ietf.org/html/draft-ietf-pcp-base-12#section-11.1
If you want/need that, please provide text.
[Tina: The proposed texts are as below:
In non-EIM NAT case, PCP client should only request the same external IP
address as the one of those existing links for one application. The
reason is that it will allow application that use multiple ports originating
from the same internal IP address to also have the same
external IP address.]

-d

> Dave Thaler
> Dave Thaler

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Jun 2011 11:26:39 -0700

I changed the subject on this thread to better represent what is being
discussed, which is 
http://trac.tools.ietf.org/wg/pcp/trac/ticket/24, "PCP mappings same public
IP address as dynamic mappings".

More below.

> From: Tina Tsou [mailto:[email-masked]]
> Sent: Tuesday, June 07, 2011 11:17 AM
> To: 'Dan Wing'; 'Dave Thaler'; [email-masked]
> mapping. 

Agreed.

> The implicit mapping will not match in this case.  If the connection

Sorry, I do not understand the previous two sentences.

> from the same internal IP address to also have the same

I think see what you're wanting the document to say.  

How about this proposed text, instead:

  If there is already an active explicit dynamic mapping,
  it will be mapped to a certain external IP address.
  When the PCP client makes another explicit dynamic mapping,
  it SHOULD place the external IP address of the existing
  mapping into the Requested External Address of the MAP 
  request.  By doing this, all of the PCP client's explicit
  dynamic mappings will be on the same external address.

Does that say the same thing?

Is it acceptable?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Jun 2011 21:25:50 +0200

In your previous mail you wrote:

=> this is a misconception: it can use it as to convert an
implicit dynamic EIM/EIF mapping into an explicit dynamic mapping
is more than easy but this doesn't mean it is the only way or
there cannot be some constraint forbidding this. In particular
when the explicit dynamic mappings use a different external port
set (*).

Regards

[email-masked]

PS (*): resource management is a good reason to split the
external port space. Or the legal logging: explicit dynamic
mappings have far longer lifetimes so the usual trick to
log only the allocation of implicit mapping port sets is not
adapted...

---

From: Tina Tsou <[email-masked]>
Date: Tue, 07 Jun 2011 18:19:12 -0700

Dan,
Replies are in line with [Tina 1: ...].

Best Regards,
Tina TSOU

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 11:27 AM
To: 'Tina Tsou'; 'Dave Thaler'; [email-masked]
Subject: PCP Issue #24, PCP mappings same public IP address as dynamic
mappings [was RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt]

More below.

Agreed.

[Tina 1: I'm only talking about the PCP mapping case. 
If the previous connection is implicit mapping, it will not match.]

Is it acceptable?
[Tina 1: Yes, it is the same thing and I agree with the texts. Thank you,
Dan.]

-d