Subject: [pcp] last CGN requirements

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 11:19:48 +0100

Printing the new base-07, I am reading the new CGN requirement draft
(named draft-ietf-behave-lsn-requirements-01.txt but LSN was replaced
by CGN everywhere at the exception of the title).
I can get:

   REQ-6:  When a CGN loses state (due to a crash, reboot, failover to a
      cold standby, etc.), it MUST start using a different external
      address pool.

   Justification:  This is necessary in order to prevent collisions
      between old and new mappings and sessions.  It ensures that all
      established sessions are broken instead of redirected to a
      different peer.  The previous address pool MAY of course be reused
      after a second loss of state.

Three comments:
 - the MUST applies to all mappings: static, explicit dynamic (i.e.,
  instantiated by PCP) and implicit dynamic.

 - it does not say something about the use of stable/persistent storage
  to remove the condition (i.e., the when).

 - it is a pure operational requirement, for instance the MAY does not
  make sense from a security point of view for long term mappings,
  i.e., static or explicit dynamic.

There are other interesting points (REQ-1 for instance) but IMHO it is
unfinished: logging section does not use the fact EIM is required for
instance.

Regards

[email-masked]

PS: Simon, I believe you want more comments?

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 13:14:11 +0100

Hi all,

REQ-6 is an operational requirement which require more elaboration: e.g., how an address pool is defined? Is there any hold-timer for the re-use of the address pool?

For operational requirements, I would prefer having something as what is documented in http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-06.

In draft-xu-behave-stateful-nat-standby-06, you may read this requirement which I would like see integrated in the CGN requirement I-D:

   "Port forwarding entries SHOULD be stored in permanent storage
   whatever the deployed redundancy mode."

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mardi 15 mars 2011 11:20
À : [email-masked]
Objet : [pcp] last CGN requirements

Three comments:

Regards

PS: Simon, I believe you want more comments?
_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Mar 2011 08:57:24 -0400

>   instantiated by PCP) and implicit dynamic.

Yes, that's the intention.

>   to remove the condition (i.e., the when).

Are you saying that if state was written to persistent storage then we
may reuse the same pool? If so, then I agree. I would consider that case
not to be a loss of state, but rather that the CGN was temporarily
unavailable. Did I understand you correctly?

>  - it is a pure operational requirement

Not entirely. There needs to be an implementation of this functionality
(the switching of address pool on state loss).

>   for instance the MAY does not

Interesting observation. What do you think should be written instead?

> unfinished: logging section does not use the fact EIM is required for

Please let me know how we could take advantage of EIM in the logging
section.

> PS: Simon, I believe you want more comments?

Of course! But please let's continue this discussion on the behave
mailing list.

Thanks,
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: Simon Perreault <[email-masked]>
Date: Tue, 15 Mar 2011 09:04:28 -0400

On 2011-03-15 08:14, [email-masked] wrote:
> REQ-6 is an operational requirement which require more elaboration:
> e.g., how an address pool is defined?

We understand "address pool" to have the same meaning as in RFC 4787. Do
we need to add anything?

> Is there any hold-timer for the
> re-use of the address pool?

That could be something useful to add to the document. What do you propose?

> In draft-xu-behave-stateful-nat-standby-06, you may read this
> requirement which I would like see integrated in the CGN requirement
> I-D:
> 

I agree with the idea, but this needs work on terminology. "Port
forwarding entry" is not defined anywhere. We could say "static NAT
mappings", but then if they are static why do they need storing? If this
would only refer to PCP mappings then it is already covered by the PCP
document. Any idea on how we can solve this?

(But please let's continue this discussion on the behave mailing list.)

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 08:19:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, March 15, 2011 5:14 AM
> To: Francis Dupont; [email-masked]
> Subject: Re: [pcp] last CGN requirements
> 
> Hi all,
> 
> e.g., how an address pool is defined? Is there any hold-timer for the

There really isn't a /need/ for two address pools.  Rather, there is a
need to not re-use an address within "some time period".  I don't know
the time period.  It needs to be discussed.  For EXAMPLE, let's say
there is a CGN that crashes and takes 20 minutes to boot -- could it
reasonably re-use the same IP address pool?  2 minutes to boot?  4
minutes?  What is the amount of time needed.  

Today when ISPs force subscribers to change IP addresses, do they wait
a day or an hour or a minute before re-using the IP address for another
subscriber?

> For operational requirements, I would prefer having something as what
> is documented in http://tools.ietf.org/html/draft-xu-behave-stateful-
> nat-standby-06.
> 
> requirement which I would like see integrated in the CGN requirement I-
> D:
> 

If a different address pool is going to be one of the requirements,
though, such permanent storage serves no purpose.

Essentially, I think we need to up-level the requirement to what
we want to see on the wire, rather than how it should be implemented
in the CGN.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 19:25:37 +0100

=> yes: the 'when' introduces a condition.

   
=> I meant operational vs security

   
=> IMHO a SHOULD for stable/persistent storage for explicit dynamic
mappings and a MUST for static mappings. But of course this is not
coherent, BTW it was already not coherent as REQ-1 and REQ-6 are
incompatible.

   
=> by definition EIM mappings have no destination address and port
so the logs don't contain in fact mappings.

BTW as explained in draft-ietf-intarea-shared-addressing-issues-05.txt
section 12 destination logging does not work well:
   Destination logging is imperfect if multiple subscribers are
   accessing the same (popular) server at nearly the same time, it can
   be impossible to disambiguate which subscriber accessed the server,
   especially with protocols that involve several connections (e.g.,
   HTTP).  Thus, logging the destination address on the NAT is inferior
   to logging the source port at the server.

   
=> it was my intention but I have to check first I am registered
on the behave mailing list.

Thanks

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 15 Mar 2011 15:00:38 -0500

> the time period.  It needs to be discussed.

Hosts, firewalls, etc already have mechanisms for dealing with the arrival
of packets that don't properly belong to an established connection.  On a
host, the hold-down timer reduces the probability of conflict with a
properly-behaving remote host stack.  But a host should be prepared for the
worst case, including packets received after a reboot and/or attack packets
that attempt to interfere with existing connections.

My view is that the CGN is well advised to enforce this hold-down timer.
But as a requirement, the hold-down timer is a SHOULD.  There may be
conditions in which the timer is ignored, without creating undue risk for
"inside" hosts.

Further, reuse of an address-pool following a loss of state (reboot etc)
SHOULD wait pending the expiration of a hold-down timer.  But this ought not
be a MUST requirement, and the requirements draft ought not require the use
of an alternative address-pool following a loss of state event.

Cheers,
-Benson

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 23:58:16 +0100

the time period.

=> I know: it is the longest term of any mappings. So it is infinite
when there are some static mappings...
This just shows the idea of no re-use within a time period works only
with implicit dynamic mappings and something else (you have already
guessed which one) should be used for explicit dynamic and static
mappings.
BTW PEER doesn't change this: it cannot extend the lifetime over
the maximum.

  It needs to be discussed.  For EXAMPLE, let's say
   there is a CGN that crashes and takes 20 minutes to boot -- could it
   reasonably re-use the same IP address pool?  2 minutes to boot?  4
   minutes?  What is the amount of time needed.

=> surely at least 2*MSL but IMHO simply the maximum lifetime
of an implicit dynamic mapping (oops, RFC 5382 REQ-5 says it must
be at least 2h04mn... forget, I am joking :-).

=> I believe they don't care but technically it is wrong to wait
less than 2*MSL.

   
=> you already proposed the different address pool as a counter
measure against the port forwarding entry theft threat.
I agree but I don't like the operational consequence: they can't
be stolen but they are no longer usable.

=> I can't see how you could solve the issue this way, I should have
missed something.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 00:30:24 +0100

I disagree: for many reasons, including security expectations and
possible clock skew in logging, the hold-down of explicit dynamic
mappings (which is already a SHOULD in PCP base, cf 8.6) IMHO
must be upgraded to a MUST for CGNs.
You can argue for a MUST for a short hold-down and a SHOULD for
the existing 120s one but I think it is better to get only one.

Regards

PS: I already discussed this point in the PCP mailing list.