Subject: Re: [BEHAVE] [pcp] last CGN requirements

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,
> 
> 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?

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.
> 
> 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."

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

> 
> 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
> 
> 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?
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

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

In your previous mail you wrote:

   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.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 09:06:36 -0400

> => I believe they don't care but technically it is wrong to wait

OK so we have a proposal: wait at least 2*MSL before reusing the same
address pool.

What does MSL stand for?

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: Wed, 16 Mar 2011 09:25:09 -0400

> OK so we have a proposal: wait at least 2*MSL before reusing the same

Sorry I was not in TCP mode.

So would this be fine for UDP and ICMP also?

Thanks,
Simon

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 16:36:23 +0100

What does MSL stand for?
   
=> "maximum segment life", it is bound to TCP TIME_WAIT state and
was standardized to 120 seconds. BTW it is MSL and not 2*MSL in this case,
I propose the common wording: "120 seconds (MSL)", this gives:
"wait at least 120 seconds (MSL) before reusing the same address pool".

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 16:41:34 +0100

=> I see address pool so the value is for all mappings.
Now if the question is whether UDP and ICMP could need longer
I can't see how, so it is fine.

Regards