Subject: [pcp] brief review of base-04

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Feb 2011 15:06:06 +0100

Base-04 is full of random/unsound changes and of course
major issues of previous versions are no addressed...

Here is a short list of points I wish to get fixed in 05:

 (3 page 6)
 - internal vs target address definitions are confusing.
  It seems the rule is the internal address is either the
  source address of the request or when it exists the target
  address from the THIRD_PARTY option.

   Note as I believe the THIRD_PARTY option brings nothing
  I'd like to go back to the base-03 stuff about internal
  addresses.

 (3 page 7)
 - in Mapping Types: result of PCP requests -> result of
  PCP MAP requests

 - later:
  "E.g. a PCP request to create a mapping that
       ^ missing ',' here, request -> MAP request
  already exists as a static mapping will return a successful
  result, confirming that the requested mapping exists."

  With which assigned lifetime? Does this work too for deletion?
  IMHO the easiest is to step back to failure (not authorized)

 (5.2 page 10)
 - IMHO it is a bad idea to include the lifetime in fixed header
  and only for the assigned lifetime.
  I understand the reason but there are other ways to introduce
  a hold down on errors, a new option for instance.

 (5.2 page 11)
 - I like the halfway renewal: it makes more sense than previous
  specs.
  But I don't have the same opinion about SERVER_OVERLOADED as
  it introduces a major security issue, in particular without
  a reasonable maximum hold time.

 (5.3 page 12)
 - MALFORMED_OPTION response code -> MALFORMED_OPTION result code

 - later: in "it MUST generate a failure response": which one?
  As a general comment this kind of text should be made more
  accurate, i.e., fails -> fails with XXX result code.

 (6.1.2 page 15)
 - with a 12 octet fixed header the minimum response size is 12.
 
 - later: the wording is confusing. IMHO there should be the
  UNSUPP_VERSION case and the other error case.

 (6.1.2 page 16)
  - (twice) i.e. -> i.e.,

 (6.1.4 page 17)
  - there is an ambiguity about the Epoch: the text says "Mappings"
   but if a NAT loses its implicit dynamic mappings but not its
   explicit dynamic mappings should it reset its Epoch?
   BTW it is not possible to directly recover from the lost of
   implicit dynamic mappings so my opinion is the answer should
   be no, i.e., only the persistence of explicit dynamic mappings
   (and static mappings even they are out of scope) matters.

 (6.2 page 18)
  - "other fields assigned by the PCP server set to 0" is obviously
   not enough. BTW at least the Epoch value is an exception...

 (6.3.1 page 18)
  - please add a reference to the figure (which is unfortunately
  on another page): the current text is unreadable.

 (6.3.1 page 19)
  - PLEASE DON'T USE "TBD" VALUES

 (6.3.1 page 19)
  - I suggest has length: 1 -> has length: >= 1
   in order to support more than 4 unprocessed options
   (even I don't believe it'll happen :-)

 (7.3 page 22) last sentence: hte -> the

 (8 page 23)
  - (twice) public -> external
   (BTW not only 'public address' is not defined but it is not
    a synonym as it is more specific)

 (8.1 page 24)
  - request and response packet formats were aligned so either
   they are going to be aligned again or this sentence removed
   (of course I prefer the first solution)

 - later: it doesn't make sense to keep the requested lifetime
  in the OpCode when it was moved to the header, I strongly suggest
  to go back to the previous layout with the lifetime in the
  OpCode part.

 - later: the Protocol field description was lost in editing...

 (8.1 page 25) e.g. -> e.g.,

 (8.2 page 26)
  - IMPLICIT_MAPPING_EXISTS (ex AMBIGUOUS) was forgotten

 (8.3 page 26)
  - the "an all-zero internal IP address" should be a
   an all-zero target IP address shouldn't it?

 (8.[34] pages 26-29)
  - the current organization is a full mess, for instance
  why the text of the previous point is in processing a
  response when obviously it is about forming a request?

 (8.3 page 27)
  - please remove external stuff from
   "A response is matched with a request by comparing the protocol,
   internal IP address, internal port, external address and external
   port."

 (8.3 page 27)
  - please add the protocol (set to 0) into
   "To do this, the PCP client sends a MAP request with external port,
   internal port, and lifetime set to 0." 

 (8.4 page 28)
  - please detail:
   "the PCP server MUST return a response indicating that
   the assigned external port is the same as the internal port."

 (8.4.2 page 29)
  - If I understand well the new lifetime rules, when the
   requested lifetime is > 0 but 'too small' it is round up
   to the minimum (120 seconds), isn't it?

 (8.4.4 page 30)
  - as I already complained about, subscriber renumbering raises
  a security issue too.

 (8.5.1 page 31)
  - the restriction for DS-Lite is a (too) strong constraint.

  - later: it doesn't make sense to give decisions about the
   local home security to the ISP.

   In conclusion this new option doesn't bring more security.
  At the opposite it clearly removes functionality.

 - later: I have no idea at all about the use of the protocol field.

 - this option is partially defined (there is a form for option
  definition, please use it)

 (8.5.2 page 32)
  - MAP44, ... -> MAP4, ...

 (8.5.3 page 33)
  - the MUST NOT is silly: I'd like to be free to use the option,
  i.e., I'll publish code using it and not only for IWF.

 (8.6 pages 34 & all)
  - to be replaced by the specific document so I simply ignore it

 (9.1 page 36)
  - issue again about "share a similar packet layout for
   both requests and responses."

 (9.1 page 37)
  - note the internal address field was kept.

  - later: Requested lifetime too.

 (9.4 page 40)
  - please define "its configured maximum lifetime value"
   (I have no idea about what this means)

 (10.1.3 page 41)
  - BTW Plain IPv6 Mode is trivially incompatible with the new MAPx's.

 (11 pages 44 & all)
  - to be replaced by the specific document so I simply	ignore it

 (12 pages 47-48)
  - still nothing about explicit dynamic mapping theft...
   Seriously you have less than 4 weeks to fix this or
   the PCP WG session at Prague will be 'intesting'.
   (http://en.wikipedia.org/wiki/May_you_live_in_interesting_times)

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Feb 2011 18:14:28 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Wednesday, February 09, 2011 6:06 AM
> To: [email-masked]
> Subject: [pcp] brief review of base-04
> 

Editing error.  The definition should be talking about the 
THIRD_PARTY option, rather than a Target Address.  Corrected
on my local version.

>   I'd like to go back to the base-03 stuff about internal

Using a separate option brings several advantages that I 
described in another email (which is in flight to the PCP
mailer as I type this response).

>  - in Mapping Types: result of PCP requests -> result of

Fixed.  Thanks.

>        ^ missing ',' here, request -> MAP request

Fixed.  Thanks.

>   With which assigned lifetime?

With the lifetime the PCP server wants to use.  Typically,
the PCP server would extend the lifetime based on the
requested-lifetime.  Does this need to be spelled out in
this example??

> Does this work too for deletion?

Yes, section 8.4 says:

  " If the PCP client attempts to delete a mapping that
   does not exist, the success response code is returned."

>   IMHO the easiest is to step back to failure (not authorized)

I don't follow.

>   a hold down on errors, a new option for instance.

There are two issues here:  (1) adding a RETRY field, and (2)
overloading that field to indicate lifetime (on success
responses) and retry (on error responses).

Yes, a separate option might be better.  I had text in an interim 
version of the document that did exactly that.  It didn't seem the
best way to handle retries -- especially for things like 
malformed requests, where the response's RETRY_IN option 
would (?) need to be at the end of the copied request.

Would removing the overloading be acceptable?  That is,
just have the field in the common header indicate the
RETRY value, and leave LIFETIME in the OpCodes themselves?

>   a reasonable maximum hold time.

I'm sorry, what is the major security issue?  That an on-path device
might spoof the PCP Server and send back SERVER_OVERLOADED??  Or
something else?

>  - MALFORMED_OPTION response code -> MALFORMED_OPTION result code

Tx.  Fixed.

>  - later: in "it MUST generate a failure response": which one?

Added "with code UNSUPP_OPTION or MALFORMED OPTION (as appropriate)".

>   accurate, i.e., fails -> fails with XXX result code.

Most of the client processing and server processing needs a
serious cleanup.  I acknowledge that still needs to be done.

>  - with a 12 octet fixed header the minimum response size is 12.

Thanks.  Fixed.

>   UNSUPP_VERSION case and the other error case.

I moved the existing version text into its own new section,
and added a pointer to that section.

>   - (twice) i.e. -> i.e.,

Fixed.

>    be no, i.e., only the persistence of explicit dynamic mappings

Agreed.  Clarified with:

          If the PCP server resets or loses the state of its
          explicit dynamic Mappings (that is, those mappings created
          by PCP MAP requests), it MUST reset its Epoch time to 0.

>    (and static mappings even they are out of scope) matters.

I don't see the value in that, because the PCP client can't recreate
those anyway.

>   on another page): the current text is unreadable.

Ok.

>   - PLEASE DON'T USE "TBD" VALUES

It's a simple #define to change the values.  I'll make it 1.

>    (even I don't believe it'll happen :-)

Doing so complicates the protocol, and adds another test case that
is likely to be missed.  If we need more than 4, I would rather
just double this up to 8, and still allow this option to appear
only once.  It seems 4 is sufficient.  But, we have the space
so I will double its size.

>  (7.3 page 22) last sentence: hte -> the

Thanks, fixed.

>     a synonym as it is more specific)

Thanks.  Fixed.

>    (of course I prefer the first solution)

Sorry, that change wasn't intentional.  Fixing that in the next
version so the response aligns with the request.

>   to go back to the previous layout with the lifetime in the

Editing mistake.  I expect have a separate thread on overloading
Lifetime/Retry_In, based on that other email I sent to the PCP
mailing list.

>  - later: the Protocol field description was lost in editing...

Fixed.

>   - IMPLICIT_MAPPING_EXISTS (ex AMBIGUOUS) was forgotten

Re-added similar text from an earlier version,

        <t>If the response code is IMPLICIT_MAPPING EXISTS, it
        indicates the PCP client is attempting to use MAP when an
        implicit dynamic connection already exists for the same
        internal host and internal port.  This can occur with certain
        types of NATs.  When this is received, the PCP client has to
        choose a different internal port and send a new PCP request
        specifying that port.</t>

>    an all-zero target IP address shouldn't it?

Editing error in the definition section; everything is now
using 'internal IP address'.

Is 'target IP address' clearer than 'internal IP address'?  
Thinking about it now, it feels clearer to use 'target'.  
Thoughts?

>   response when obviously it is about forming a request?

Agreed.  Right now it is:

   [Client] Generating and Sending a Request
   [Client] Processing a Response   
   General PCP Server Operation

I plan change the organization for general, MAP, and PEER have the following
document layout:

  x.y. Processing Requests and Responses
  x.y.1.  client generating a request
  x.y.2.  server processing a request and generating a response
  x.y.3.  client processing a response

>    internal IP address, internal port, external address and external

Thanks for catching that.  Fixed.

>    internal port, and lifetime set to 0."

Done.

>    the assigned external port is the same as the internal port."

Clarified to read:

        If the requested external port is 0, and the PCP-controlled
        device does not change port numbers (that is, it does not do
        port translation), and the PCP-controlled device permits all
        ports to be forwarded to the internal IP address, the PCP
        server generates successful response with assigned external port 
        set to 0.

>    to the minimum (120 seconds), isn't it?

Yes.  That's been the case since draft-ietf-pcp-base-00.  But
I recall you mentioned there is a problem with that when
interworking with other protocols.  The intent of the PCP
server's configured minimum is to avoid PCP protocol 
chatter with really short lifetimes.  Clearly a one second
lifetime is silly, as it will time out before a refresh
can be performed, and the client is likely to lose incoming
data.  120 seconds feels a reasonable suggestion for many 
networks.

>   - as I already complained about, subscriber renumbering raises

The text in 8.4.4 of -04 already says:

   "This same
   problem can occur if an IP address is re-assigned today, without PCP
   and without an ISP-operated CGN.  The solution is the same as today:
   the problems associated with subscriber renumbering are eliminated if
   the ISP avoids re-assigning IP addresses to different subscribers."

I do not see anything that PCP can do about an ISP renumbering a
subscriber and the related mis-direction of traffic to the subscriber's
old IP address.

>   - the restriction for DS-Lite is a (too) strong constraint.

It says:

   For Dual-Stack Lite deployments, the PCP server only supports this
   option if the source IPv4 address is the B4's source IP address.

the reason for that restriction is that if a DS-Lite user wants to
set up a 3rd party mapping, the user has to first authenticate 
themselves to the B4 device (e.g., HTTP login using their 
administrative password), and then have the B4 issue the PCP
request with the THIRD_PARTY option.

Any other restriction to the use of THIRD_PARTY starts moving us
towards requiring the CGN and the subscriber to share a password.

If you, or anyone, has a better idea, I'm all ears to hear about it.

>    local home security to the ISP.

It isn't.  The decision rests with the home user that can
login to the B4 element on their premises.

If you, or anyone, has a better idea, I'm all ears to hear about it.

>    In conclusion this new option doesn't bring more security.

It is not intended to bring more security.

It is intended to simplify the PCP client's operation, make
the intent for a 3rd party mapping clearer (presence or
absence of an option is clearer than comparing IP address 
in the PCP payload with source IP address).

>   At the opposite it clearly removes functionality.

The THIRD_PARTY option does not remove functionality at all.  
I do concur that the limit on dual-stack lite, namely:

   For Dual-Stack Lite deployments, the PCP server only supports this
   option if the source IPv4 address is the B4's source IP address.

does remove functionality.  That is intended.  And that is
functionality that could have equally well been removed with
the -03 packet layout (which had internal-ip-address in the
MAP payload).

>   definition, please use it)

I just noticed a mistake in -04.  THIRD_PARTY needs a different 
definition than what is in -04.  Specifically, the current text 
assumes the MAP4 OpCode or MAP6 OpCode dictates the address
family of the internal IP address.  However, that is only
true with a firewall, NAT44, or NAT66.  It wouldn't be true
with NAT64 or NAT46.  So, I just adjusted it to read:

              <t hangText="Mapping Internal IP Address:">Internal IP
              address of the mapping. If the length of this Option is
              1, this is a 32-bit IPv4 address.  If the length of this
              Option is 4, this is a 128-bit IPv6 address.</t>

>   - MAP44, ... -> MAP4, ...

Thanks.  Fixed.

>   i.e., I'll publish code using it and not only for IWF.

I guess you're referring to

   PCP clients
   other than IGD interworking clients MUST NOT use this option because
   it results in inefficient operation, and they cannot safely assume
   that all PCP servers will implement it.

>   - to be replaced by the specific document so I simply ignore it

You're referring to:

   8.6.  PCP Mapping State Maintenance  . . . . . . . . . . . . . . 34
     8.6.1.  Recreating Mappings  . . . . . . . . . . . . . . . . . 34
     8.6.2.  Maintaining Mappings . . . . . . . . . . . . . . . . . 35

? 

I don't believe there are plans to remove that to a separate document -- the
only plans to remove anything to a separate document are UPnP interworking
(which isn't covered in 8.6), and the nested NAT (which will eventually be
published as draft-wing-pcp-nested-nat, using ideas I have presented at the
PCP interim meetings, ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf).

>    both requests and responses."

This is related to the removal of lifetime.  Let's figure out how to
solve that in the other thread, and I'll make them align.  This is
an inadvertent editing mistake.

>    (I have no idea about what this means)

adjusted to read:

  Otherwise, the PCP server chooses the smaller of the
  requested lifetime and its configured maximum lifetime value (which
  might be the same value as for PIN mappings
  (<xref target="lifetime"></xref>), or might be a different value), and
  sets the lifetime of the existing mapping.

>   - BTW Plain IPv6 Mode is trivially incompatible with the new MAPx's.

For reference, it -04 says:

   10.1.3. Plain IPv6 Mode

   Another alternative for deployment of PCP in a DS-Lite context is to
   rely on a PCP Proxy in the B4 element.  Protocol exchanges between
   the PCP Proxy and the PCP server are conveyed using plain IPv6 (no
   tunnelling is used).  Nevertheless, the IPv6 address used as source
   address by the PCP Proxy MUST be the same as the one used by the B4
   element.

I don't see the incompatibility.  When the B4 element receives
PCP requests from hosts, and wants to send them to the server, it
adds the THIRD_PARTY option to the request.  Seems compatible to my
mind.

>   - to be replaced by the specific document so I simply	ignore it

Fair.

>    (http://en.wikipedia.org/wiki/May_you_live_in_interesting_times)

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 10:47:23 +0100

=> I don't see these advantages nor a discussion of this
major change in the list.

   
=> I can't parse your answer: we are talking about *static*
mappings so they have by definition infinite lifetimes.

   Yes, section 8.4 says:

=> in this text the 'a mapping' is 'an explicit dynamic
mapping' so what happens when a request is received
for the deletion of a static mapping?
Note I consider that PCP allowed to delete static mappings as
a security concern.

   I don't follow.
   
=> I propose to return the NOT_AUTHORIZED (or a better new
result code) result code for operations on static mappings.

   
   
=> I've understood this was the reason for your choice but
a malformed request by definition raises a permanent error
so there is no need for a RETRY_IN option.

=> not only removing the overloading is acceptable but
it is the only acceptable option.

   
=> spoofed SERVER_OVERLOADED with silly retry values.

   Agreed.  Clarified with:

=> thanks!

   
=> oops, what I tried to suggest is to change the length from
'one only' to 'equal or greater than one'.

=> we could say it is a major security problem.

   >   - the restriction for DS-Lite is a (too) strong constraint.
   
=> yes, you can't at the same time push the encapsulation mode
for direct host - PCP server communication and add this kind of
constraints.

   It says:

=> so you adopted one of my arguments in favor of the plain mode:
the B4 should have a greater role in PCP message relaying so the
encapsulation mode simplicity is just an illusion.

=> password? is it a joke?

=> I already explained my ideas about the home security and even
there are some still open points obviously the THIRD_PARTY option
can't help at all.

   
=> quoting the 8.5.1 text:

   "the ISP MUST determine its own policy for how to identify
    the trusted device within the subscriber's home."

=> I already answered: the source address and the internal
address must share the same address family and this is new.
(note this comment is from the 04 in the repository, i.e.,
the not fixed version as it was the only available version).

   
   
=> this changes many things...

   
=> good guess

      PCP clients

   You're referring to:

=> yes
   
   I don't believe there are plans to remove that to a separate document --

=> replace != remove

   adjusted to read:
   
                                    ^^^ MAP
   
=> I still don't know what is "its configured maximum lifetime value".

=> not with the THIRD_PARTY option in the published unfixed -04.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 08:57:31 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 10, 2011 1:47 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] brief review of base-04
> 
> 

Then, let's start with the agreement that this is the 
discussion.  

Nothing is cast in stone; this is an I-D.  I am trying my 
best to simplify the protocol based on 100s of emails and
and discussions.  And I do make mistakes.

> mappings so they have by definition infinite lifetimes.

I do not understand the purpose of discussing static mappings
(created with a CLI) and how/why they affect PCP or how/why
they affect implicit dynamic mappings (e.g., TCP SYN).  Is 
there an application or a protocol that breaks if they get 
assigned different public IP addresses?  I can see where 
PCP and implicit dynamic mappings need to be on the same
public IP address.  But I don't see a similar need for
static mappings (created with a CLI) to be on the same
public address.  And I don't believe the PCP specification
can create such a rule, either; obviously the PCP 
specification can't create a rule that implicit dynamic
mappings and static mappings have to be on the same public
IP address, because PCP is only defining PCP and can only
define rules for itself.

> for the deletion of a static mapping?

Static mappings can't be deleted by PCP.  That is the 
purpose of the UNABLE_TO_DELETE_ALL result code:

  "If the PCP client attempts to delete
   a port mapping which was manually assigned by some kind of
   configuration tool, the PCP server MUST respond with
   UNABLE_TO_DELETE_ALL result code, but the other fields are encoded as
   described above."

> => I've understood this was the reason for your choice

Good.  I wasn't sure if the reason for the change was understood.
Thanks.  That's something.

> but

That concern is not unique to SERVER_OVERLOADED, is it?

> 'one only' to 'equal or greater than one'.

I understand that was your suggestion.  But this gets risky, because
(a) this is an error condition, and we all know that error paths
in code are never as well-tested as success paths, (b) this error
condition would be the only PCP option defined in the base 
protocol that can occur multiple times, (c) the only way to cause
this error is to send a PCP request with a bunch of not-yet-defined
mandatory-to-process options.  These code paths would not be 
very robust in the client or the server.

> => we could say it is a major security problem.

But ISP renumbering is not unique to PCP (PCP doesn't cause the
renumbering), and ISP renumbering is not made worse because of
the existence of PCP (nor is ISP renumbering made worse because
of the existence of a CGN or a firewall).

> encapsulation mode simplicity is just an illusion.

I welcome assistance with adjusting the text discussing 
Encapsulation/Plain mode.

>       that all PCP servers will implement it.

And you'd like it to be a SHOULD NOT?  It _does_ result in inefficient
operation, and I can certainly see how a CGN would want to deprecate
(not support) that option in the future, because a requested-for port
simply cannot be forced (it will already be used by another subscriber).

>      might be the same value as for PIN mappings

Tx, fixed that.

> => I still don't know what is "its configured maximum lifetime value".

A CLI setting, a #define'd value, or so on.

> => not with the THIRD_PARTY option in the published unfixed -04.

Yes, I made a mistake in -04.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 18:58:18 +0100

=> it is a formal point: the discussion is supposed to happen
before, not after. BTW this is not your responsability,
it is chairs' one.

=> yes as a human you can make mistakes and don't like to
go backward (:-).

   I do not understand the purpose of discussing static mappings
   (created with a CLI) and how/why they affect PCP or how/why
   they affect implicit dynamic mappings (e.g., TCP SYN).

=> IMHO the only question is whether they are manageabled by PCP
and IMHO again the answer should be 'no'.

   Is there an application or a protocol that breaks if they get 
   assigned different public IP addresses?

=> yes, this is why the behave WG produces a requirement saying
all mappings of the same subscriber must get the same external
address.

   I can see where 
   public address.

=> explicit dynamic mappings and static mappings are not so
different: they are two kinds of port forwarding.

   And I don't believe the PCP specification
   
=> I plainly agree: the PCP specs should only refer to
behave WG documents.

   
   
=> hum, IMHO the wording should be changed to 'a not explicit
dynamic mapping' so it will be clear a PCP delete works only
on PCP created mappings. BTW this can lead some implementations
to return this result code for any not specific delete request
but I can't see why it should be an issue.

   
=> not unique but SERVER_OVERLOADED has no justification.

   protocol that can occur multiple times,

=> (b) is another way to handle more than 4 unsupported options.
It is a matter of taste.

   
=> we have a rule in France: you opened the wine bottle, now you have
to drink it. So as you consider this problem you should not stop
at its bad operational consequences, but to its even worse security
consequences. BTW a reference to the security considerations should
be enough (of course *improved* security considerations).

=> I use it for renewals and I'll continue to use it in this case,
so I don't really care...
BTW it is easy to support in a CGN and the fact it doesn't work in the
real world is not the CGN programmer fault (I know we agree about this
point).

   
=> so it is a new and PCP specific NAT property.

Regards

PS: I sent three large messages to the list:
 - a counter-proposal for the internal address issue

 - another one about errors

 - an updated version of the security model

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 11:22:42 -0800

> Sent: Thursday, February 10, 2011 9:58 AM
> To: Dan Wing
> Cc: [email-masked]

BEHAVE only says the implicit dynamic mappings need to be
on the same public IP address.

I expect PCP needs to also have its explicit dynamic mappings
on that same public IP address.

> different: they are two kinds of port forwarding.

I don't see how we can do anything more than "SHOULD be
the same", though.  Afterall, PCP is not defining how
static (CLI) mappings are done.

> but I can't see why it should be an issue.

How is this:

        PCP MAP requests only control
        mappings created by MAP requests.  So, f the PCP client
        attempts to delete a static port mapping (i.e., a mapping
        created outside of PCP itself), the PCP server deletes all of
        the PCP-created mappings but MUST respond with
        UNABLE_TO_DELETE_ALL result code, with the other fields
        encoded as described above.

> => not unique but SERVER_OVERLOADED has no justification.

Ok.  Let's separate the two problems.  I do agree that the
PCP server can simply discard PCP messages if it's too busy.
The expectation of SERVER_OVERLOADED is similar to IP's
ECN (early congestion notification), to provide back-pressure
*before* the server is completely overloaded.  Of course
once completely overloaded, it is cheaper (less processing)
to discard packets rather than generate a SERVER_OVERLOADED
response.

> be enough (of course *improved* security considerations).

Yes.  And I hope to work security considerations today.

> => so it is a new and PCP specific NAT property.

Not at all.

Every NAPT, today, has a configured maximum lifetime value.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Feb 2011 01:25:32 +0100

=> BEHAVE says:
 "REQ-1: A LSN MUST allocate one external IP address to each CPE."

i.e., there is nothing explicit which limits the requirement
to a particular mapping type.

=> I agree and we should refer to BEHAVE as this is not in
the PCP WG scope.

   
=> we can refer to the BEHAVE MUST and apply it to all mappings.
Of course it should be fine to check with the BEHAVE WG too.

   How is this:
   
                                                 ^i
   
=> it is in the section >= 3 so the word 'port' is not needed.
But my suggestion was not to apply this to static mappings but
to all not explicit dynamic mapping, i.e., what is inside the
parentheses.

   Ok.  Let's separate the two problems.  I do agree that the
   PCP server can simply discard PCP messages if it's too busy.
   The expectation of SERVER_OVERLOADED is similar to IP's
   ECN (early congestion notification),

=> no, it is similar to the source quench ICMP.

   to provide back-pressure
   
=> when we discussed the ticket #11, there was a consensus
to not introduce a flow control mechanism. So you have to
reopen #11 first...

   Not at all.

=> they have many, one per condition, for instance my AFTR has
5 different configured maximum lifetimes... so I have nothing
against a 6th one (:-).
   
Regards

PS: UDP, ICMP echo, TCP (opening, open, closing). And I don't
count fragment and hold down. BTW I don't believe you want
the open TCP one even it is usually the largest because
it would be simpler to send a TCP probe.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 17:03:42 -0800

> Sent: Thursday, February 10, 2011 4:26 PM
> To: Dan Wing
> Cc: [email-masked]

Adjusted that text.

The 'maintaining external address' is venturing beyond the MAP
OpCode itself, so I moved it to a new section and rewrote most
of it.  I now have this.  You will see the text requires implicit
and explicit mappings be the same, and recommends static mappings
be the same.  I am still struggling to understand what breaks
if static mappings are different -- "NAT load balancing" doesn't
explain the problem to me.  

   10.  Considerations for MAP and PEER OpCodes
   10.1.  Maintaining Same External IP Address

   It is REQUIRED that the PCP-controlled device assign the same
   external IP address PCP-created explicit dynamic mappings and to
   implicit dynamic mappings.  It is RECOMMENDED that static mappings
   (e.g., those created by a command language interface on the PCP
   server or PCP-controlled device) also be assigned to the same IP
   address.

   Once all internal hosts belonging to a given subscriber have no
   implicit dynamic mappings and have no explicit dynamic mappings in
   the PCP-controlled device, a subsequent PCP request for that internal
   host MAY be assigned to a different external IP address.  Generally,
   this re-assignment would occur when a CGN device is load balancing
   newly-seen hosts to its public IPv4 address pool.

> => no, it is similar to the source quench ICMP.

Yes, it's quite similar to source quench.

Which fell out of favor because off-path attackers could spoof
the ICMP source quench, because ICMP source quench didn't include
much information in the packet, and TCP implementations didn't
validate the data that was contained in them.  Very much like
the off-path RST attacks described in various papers that can
still happen today (with large windows).

> to not introduce a flow control mechanism. So you have to

Ticket #11 was only about existing contradiction in that
version of the specification.  The decision was to allow
the client to send traffic however fast it wanted.

I'll go read your proposal on how to handle errors.  I 
believe there is a good idea in there that should bear
some fruit towards moving us all forward.

> 5 different configured maximum lifetimes... so I have nothing

No, it is still not a new lifetime.

A TCP connection, once established, has a lifetime.  This is
the amount of time that no data is sent or received across
the TCP session before the NAT times it out.  This has
a value, let's call it the "configured maximum lifetime
value".  That is the value returned.

Please suggest a wording change if the existing text is
unclear.  I don't see how to improve it.

Text reads:

  "Otherwise, the PCP server chooses the smaller of the
requested lifetime and its configured maximum lifetime value (which
might be the same value as for mappings (created with the MAP
OpCode, <xref target="lifetime"></xref>), or might be a different
value), and sets the lifetime of the existing mapping."

-d