Subject: [pcp] learning the external address

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Oct 2011 15:13:08 +0200

I am not happy with section 9.7 "Learning the External IP Address Alone",
first the term "costemic" ignores this is required to implement IWF,
second the proposed solution is inefficient and underspecified.
In conclusion this seems as nobody cares about addressing the problem...

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 14:03:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, October 13, 2011 6:13 AM
> To: [email-masked]
> Subject: [pcp] learning the external address
> 

Then create a mapping, and keep the mapping alive.  If it expires,
the CGN is fully within its rights to change your IP address.  Same
as with DHCP -- once your lease expires you cannot reasonably expect
to get the same IP address later (it may have been given to somebody
else).

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Oct 2011 23:22:44 +0200

> In conclusion this seems as nobody cares about addressing the
   
   Then create a mapping, and keep the mapping alive.

=> it is the obvious solution but IMHO it is important enough to get
its own document.

   Same as with DHCP -- once your lease expires you cannot reasonably
   expect to get the same IP address later (it may have been given to
   somebody else).
   
=> in fact I have seen only two behaviors from DHCP servers; either
they try hard to always give the same address, or they try hard
to change the address after a known delay, typically each 24 hours,
and reseting the underlying layer so no relying on the lease expiry...

I expect to get the same thing(s) with CGNs and BTW I already suggested
to change MAP and PEER responses to include the assigned external
address when the NAT has one (only one, i.e., not none or more than one)
external address candidate for the PCP client. Note to copy the
suggested external *address* to the response is useless...

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 14:36:05 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 13, 2011 2:23 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] learning the external address
> 
> 

Without a lifetime for that address, it is irresponsible to
tell the client the external IP address -- even if there is only
one external IP address.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 10:16:46 +0200

=> so it is irresponsible to implement an IWF because both
NAT-PMP and UPnP IGD (v1 or v2) provide a primitive which
returns the external IP address without a lifetime.
BTW is it the official position of the WG?

Regards

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Oct 2011 07:46:08 -0400

> BTW is it the official position of the WG?

FWIW, I don't agree with that position.

Keith

---

From: Simon Perreault <[email-masked]>
Date: Fri, 14 Oct 2011 09:00:22 -0400

> BTW is it the official position of the WG?

I disagree. PCP should do things the right way (i.e. with a lifetime).
The IWF is allowed to be hackish to accommodate broken protocols (i.e.
strip off the lifetime).

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 07:47:58 -0700

> From: Keith Moore [mailto:[email-masked]]
> Sent: Friday, October 14, 2011 4:46 AM
> To: Francis Dupont
> Cc: Dan Wing; [email-masked]

Get a mapping, and maintain that mapping.  It is not PCP's
responsibility to perpetuate a mistake in UPnP IGD and in
NAT-PMP.

> FWIW, I don't agree with that position.

I don't see how to reconcile that 

  1.  networks change, and nothing lasts forever.  Hence,
      DNS has TTLs, lack of route advertisements means the
      route is no longer valid, DHCP has leases, and so on.
  2.  UPnP IGD and NAT-PMP both assume the IP address lasts
      forever.  It does not last forever.

-d

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Oct 2011 12:04:59 -0400

>      forever.  It does not last forever.

An IP address binding does not last forever, because nothing lasts forever.   But it might last indefinitely.  NATs can be stateless, firewalls can have static rules.   

My understanding is that DHCP leasing was designed based on the assumption that PCs crash or get shut down without any warning.  If DHCP handed out addresses to PCs without some sort of expiration, eventually all of those addresses would be assigned to PCs that had crashed and lost their memory of previous address assignments.   Unfortunately, that design choice in DHCP led to a mentality that said that the network could change an address binding for frivolous reasons.  That was an unintended consequence, and not a desirable one.  The Internet architecture didn't then, and still doesn't, have a good, widely-applicable mechanism for allowing applications to tolerate addresses being changed out from under them.

DNS TTLs are similarly problematic, at least as a sole mechanism.  Obviously there's a need to expire stale RRs from caches.  But TTLs are at best a stopgap mechanism.  The problem is that you rarely know in advance when a RR needs to change, and even when you do, DNS doesn't give you a mechanism to gracefully manage that change.   Really you need additional mechanisms: the ability to instantly update or at least delete all replicas when an RR changes (dynamic update does address this problem to some degree); and for those cases where you do know in advance that an RR will change, you would like to have the ability to pre-propagate the new RR in advance of it being advertised, and set an absolute expiration date-time on the old RR (which would effectively cause the TTL on the old RR to decrease down to zero as that expiration date-time approached).

So I don't think either DNS or DHCP should be cited as good examples of how to manage cached bindings with finite lifetimes.

What I disagree with in the quoted statement above is that it's "irresponsible" to tell a client an external IP address without a lifetime.  What might be irresponsible is making up a lifetime where one did not exist.   If the binding is of indefinite duration, the protocol should allow the NAT or firewall to say so.  

Realize also that even a DNS TTL or a DHCP lease time is no guarantee that the binding will be valid for that long.  RRs do get updated without advance notice; routers (especially consumer-grade routers) get wedged and have to be rebooted, causing all of their old leases to be forgotten.    For similar reasons, a stated lifetime in a PCP binding can't be expected to be a guarantee either.  But a TTL is a poor mechanism for dealing with that case.

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 09:55:43 -0700

> Sent: Friday, October 14, 2011 9:05 AM
> To: Dan Wing
> Cc: 'Francis Dupont'; [email-masked]
> An IP address binding does not last forever, because nothing lasts
> forever.   But it might last indefinitely.  NATs can be stateless,
> firewalls can have static rules.
> 
> My understanding is that DHCP leasing was designed based on the
> assumption that PCs crash or get shut down without any warning.  If
> DHCP handed out addresses to PCs without some sort of expiration,
> eventually all of those addresses would be assigned to PCs that had
> crashed and lost their memory of previous address assignments.
> Unfortunately, that design choice in DHCP led to a mentality that said
> that the network could change an address binding for frivolous reasons.
> That was an unintended consequence, and not a desirable one.  The
> Internet architecture didn't then, and still doesn't, have a good,
> widely-applicable mechanism for allowing applications to tolerate
> addresses being changed out from under them.
> 
> DNS TTLs are similarly problematic, at least as a sole mechanism.
> Obviously there's a need to expire stale RRs from caches.  But TTLs are
> at best a stopgap mechanism.  The problem is that you rarely know in
> advance when a RR needs to change, and even when you do, DNS doesn't
> give you a mechanism to gracefully manage that change.   Really you
> need additional mechanisms: the ability to instantly update or at least
> delete all replicas when an RR changes (dynamic update does address
> this problem to some degree); and for those cases where you do know in
> advance that an RR will change, you would like to have the ability to
> pre-propagate the new RR in advance of it being advertised, and set an
> absolute expiration date-time on the old RR (which would effectively
> cause the TTL on the old RR to decrease down to zero as that expiration
> date-time approached).
> 
> So I don't think either DNS or DHCP should be cited as good examples of
> how to manage cached bindings with finite lifetimes.
> 
> What I disagree with in the quoted statement above is that it's
> "irresponsible" to tell a client an external IP address without a
> lifetime.  What might be irresponsible is making up a lifetime where
> one did not exist. 

Well, no matter if a subscriber gets their IP address via PPPoE 
(which doesn't have a concept of lease duration in IPCP)
or via DHCP (which has a lease duration).

> If the binding is of indefinite duration, the
> protocol should allow the NAT or firewall to say so.
>
> Realize also that even a DNS TTL or a DHCP lease time is no guarantee
> that the binding will be valid for that long. 

Never said it was.  It's an indication that the information may
not be valid beyond that time.

> RRs do get updated
> without advance notice; routers (especially consumer-grade routers) get
> wedged and have to be rebooted, causing all of their old leases to be
> forgotten.    For similar reasons, a stated lifetime in a PCP binding
> can't be expected to be a guarantee either.  But a TTL is a poor
> mechanism for dealing with that case.

Here is some Dan <philosophy>:  the socket APIs were designed back
in the days of the hosts file, when things were static.  The
introduction of DNS, which should have inspired movement towards
a more dynamic API to translate hostsnames to addresses, did not
cause such inspiration.  getaddrinfo defined in RFC3493 didn't
do it, either.  Networking, by its nature, is dynamic.  Encouraging
implementation

A thought experiment:  if we were to return an address and indicate 
it has infinite duration, and the ISP renumbers their network (or
the subscriber moves from ISP-A to ISP-B, due to cost or
dynamically because of failure of ISP-A) -- do we want a self-
recoverable system, or do we want a system that forces the
user to take manual action?

I would want a self-recoverable system, and the way I see
to achieve that is by having the PCP occasionally ask if
the mapping is still valid, exists, and has the same IP
address.  This causes applications to be coded expecting
these changes that do, really, occur in real life.  And
results in a better-working Internet for everyone.
</philosophy>

-d

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Oct 2011 13:02:23 -0400

> do it, either.  Networking, by its nature, is dynamic.  Encouraging

So let's make TCP and UDP address agile, with secure update.   Or define them in terms of tokens that aren't IP addresses, and build a mapping layer between endpoint identifiers and addresses that is fast, robust, low-overhead, and secure, and works well for both fixed and mobile hosts networks.   Anything short of that doesn't solve the problem.   LISP is making a stab at it, and so is HIP, but last I knew both of them still fell way short of fixing the problem.

> user to take manual action?

I want a self-recoverable system.  It's just that I recognize that a TTL (by itself) is a poor way to build such a system.

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 12:39:36 -0700

> Sent: Friday, October 14, 2011 10:02 AM
> To: Dan Wing
> So let's make TCP and UDP address agile, with secure update.   Or
> define them in terms of tokens that aren't IP addresses, and build a
> mapping layer between endpoint identifiers and addresses that is fast,
> robust, low-overhead, and secure, and works well for both fixed and
> mobile hosts networks.   Anything short of that doesn't solve the
> problem.   LISP is making a stab at it, and so is HIP, but last I knew
> both of them still fell way short of fixing the problem.
> 
> 
> I want a self-recoverable system.  It's just that I recognize that a
> TTL (by itself) is a poor way to build such a system.

Sure.  But it's a step in the right direction.

A TTL of infinity makes it impossible, because then everything assumes
the returned values are valid until the end of time.

-d

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Oct 2011 15:48:29 -0400

> the returned values are valid until the end of time.

Nah, it just means that every application and/or host picks its own maximum retry value.  And hopefully they don't rely exclusively on PCP to tell them when a binding is changing.

Ideally there would be a mechanism by which a NAT or firewall or whatever could let its clients know when there's been a disruptive event.    Maybe by sending a message (or three) to a multicast group.

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 13:16:21 -0700

> Sent: Friday, October 14, 2011 12:48 PM
> To: Dan Wing
> Nah, it just means that every application and/or host picks its own
> maximum retry value.  And hopefully they don't rely exclusively on PCP
> to tell them when a binding is changing.
> 
> Ideally there would be a mechanism by which a NAT or firewall or
> whatever could let its clients know when there's been a disruptive
> event.    Maybe by sending a message (or three) to a multicast group.

draft-cheshire-pcp-recovery.  But that will only work if there is 
multicast between the PCP server and the client(s).  In different
environments this varies from impossible to trivial (e.g., non-
routed home network).  Impossible is that an SP isn't going to
deploy multicast between their PCP server and their subscribers
for the sole purpose of immediately informing the subscriber
equipment of an IP address change on the CGN itself.  

We need a way for PCP to work correctly without a multicast
message from the PCP server to the clients.

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 15 Oct 2011 13:30:17 +0200

=> this doesn't scale... I prefer to put stable storage on
the NAT or firewall (BTW with the legal constraint in most countries
about logging a CGN must have stable storage so in fact it should not
be a real issue).

Regards

PS: frivolous renumbering by the CGN has a critical impact on security:
Internet clients can no longer assume they talk to the right server,
and don't expect users which have to suffer from a CGN may use enough
crypto to be protected against this... my concern is the perception
is not only the IETF doesn't help these users but despises their interest.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 15 Oct 2011 13:35:29 +0200

draft-cheshire-pcp-recovery.

=> clearly a port of the similar mechanism in NAT-PMP,
and limited to the same environment (NAT embedded in the
home gateway, not a CGN).

=> I already propose one: put stable storage on the CGN so
it no longer loses its state and there is no need for
a recovery...

Regards

PS: BTW according to one of your arguments if we add the
external address to recovery messages it should be
associated with a lifetime.