Subject: [BEHAVE] Unjustified SHOULDs in CGN requirements

From: Simon Perreault <[email-masked]>
Date: Fri, 01 Jun 2012 11:24:06 -0400

Dear BEHAVErs,

During AD review of draft-ietf-behave-lsn-requirements it was pointed 
out that many requirements are at the SHOULD level but do not include 
justification for why they are not MUSTs.

Here's a list of all unjustified SHOULDs (there are 18). I'm asking the 
WG for a justification for each of them. If a SHOULD isn't justified, 
I'm going to turn it into a MUST. Note that I'm not looking for a 
justification for the requirement itself. I'm looking for a reason why 
we're saying SHOULD instead of MUST.

(1) REQ-3: The CGN function SHOULD NOT have any limitations on the size
            nor the contiguity of the external address pool.  In
(2)        particular, the CGN function SHOULD be configurable with
            contiguous or non-contiguous external IPv4 address ranges.

(3) REQ-4: A CGN SHOULD support limiting the number of external ports
            (or, equivalently, "identifiers" for ICMP) that are assigned
            per subscriber.

(4)        A.  Limits SHOULD be configurable by the CGN administrator.

(5)        C.  Additionally, it is RECOMMENDED that the CGN include
                administrator-adjustable thresholds to prevent a single
                subscriber from consuming excessive CPU resources from
                the CGN (e.g., rate limit the subscriber's creation of
                new mappings).

(6) REQ-5: A CGN SHOULD support limiting the amount of state memory
            allocated per mapping and per subscriber.  This may include
            limiting the number of sessions, the number of filters, etc.,
            depending on the NAT implementation.

(7)        A.  Limits SHOULD be configurable by the CGN administrator.

(8)        B.  Additionally, it SHOULD be possible to limit the rate at
                which memory-consuming state elements are allocated.

(9) REQ-6: It SHOULD be possible to administratively turn off
            translation for specific destination addresses and/or ports.

(10)REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent
            Filtering" behavior (as defined in [RFC4787] section 5).

(11)REQ-8: Once an external port is deallocated, it SHOULD NOT be
            reallocated to a new mapping until at least 120 seconds have
            passed

            The length of time and the maximum number of ports in this
(12)       state SHOULD be configurable by the CGN administrator.

       Note that this requirement also applies to the case when a CGN
       loses state (due to a crash, reboot, failover to a cold standby,
       etc.).  In that case, ports that were in use at the time of state
(13)  loss SHOULD NOT be reallocated until at least 120 seconds have
       passed.

(14) REQ-10:CGN implementrers SHOULD make their equipment manageable.
             Standards-based management using standards such as
             "Definitions of Managed Objects for NAT" [RFC4008] is
(15)        RECOMMENDED.

    REQ-11:  When a CGN is unable to create a mapping due to resource
             constraints or administrative restrictions (i.e., quotas):

(16)        C.  it SHOULD send a notification (e.g., SNMP trap) towards
                 a management system (if configured to do so);
(Possible justification: SNMP trap generation rate limiting?)

(17)        D.  and it SHOULD NOT delete existing mappings in order to
                 "make room" for the new one.  (This only applies to
                 normal CGN behavior, not to manual operator
                 intervention.)

(18) REQ-12: A CGN SHOULD NOT log destination addresses or ports.

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: ssenthil <[email-masked]>
Date: Fri, 01 Jun 2012 12:05:37 -0400

>             nor the contiguity of the external address pool.  In

I would disagree with turning the above SHOULD to a MUST. The reason being
that the size of the pool is directly related to the resources in the box
memory and saying that the size of the pool MUST NOT be limited is
restrictive and makes the device vulnerable. You may want to separate the
size and contiguity and make the contiguity argument as a MUST and the size
argument as a SHOULD.

>             contiguous or non-contiguous external IPv4 address ranges.
This can be changed to a MUST.

>             (or, equivalently, "identifiers" for ICMP) that are assigned

I agree that this can be changed to a MUST.

>                 the CGN (e.g., rate limit the subscriber's creation of
The above is too vague to be called a must, unless the resources are
explicitly called out.
>                 which memory-consuming state elements are allocated.
I don't see a justification on why the rate is a MUST, if I can limit based
on the other parameters like ports and sessions and memory.
>              "Definitions of Managed Objects for NAT" [RFC4008] is
CGN MUST have a MIB implemented? Seems too restrictive to me.

> (Possible justification: SNMP trap generation rate limiting?)

Any such notification will have to rate limited.

>                  normal CGN behavior, not to manual operator
Agree, this can be a MUST (NOT).

> (18) REQ-12: A CGN SHOULD NOT log destination addresses or ports.
I think this should be left upto the implementation, you can say you MUST
log the source port, but I don't think you can say you MUST NOT log
destination addresses and ports.

---

From: [email-masked]
Date: Mon, 4 Jun 2012 09:05:08 -0400

Hello Senthil, Simon.
Being on the deployment side of the equation, I agree with Senthil on 
most points, except on the MIB requirement, where the MUST makes sense 
in  my opinion. It doesn't make sense to have such a box deployed without
the capacity to monitor it properly. 

More below (no strong feeling on a point unless noted otherwise). 

> I agree that this can be changed to a MUST.

+1 on MUST. This is an important requirement for a deployment. 

> The above is too vague to be called a must, unless the resources are

This could remain a SHOULD. Rate-limiting isn't a huge plus IMHO as
long as the port-limit is present. 

> on the other parameters like ports and sessions and memory.

This looks implementation dependant. No need for a MUST here IMO. 

> >             translation for specific destination addresses and/or 
ports.

Useful. +1 on a MUST here, but no strong feeling. 

> >             reallocated to a new mapping until at least 120 seconds 
have

-1 on MUST here. I understand that the 120 seconds is there for security 
reasons, but I'm not sure I want an implementation to be limited with such 

a static number. In an environment with a very high number of short-lived
sessions, this is very limitating. 
 
> > (12)       state SHOULD be configurable by the CGN administrator.

+1 on the MUST be configurable. But this somewhat goes against (11). 
I guess an implementor will understand that the timer must be 
configurable with a lower limit of 120 seconds. 

> CGN MUST have a MIB implemented? Seems too restrictive to me.

+1 on a MUST here, as stated above. The MIB is needed for any serious 
deployment IMHO. 
 
> Agree, this can be a MUST (NOT).

+1 on the MUST NOT. 

> destination addresses and ports.

Agreed on the MUST log the source, per Senthil's suggestion. I would 
leave the destination logging an open matter. 

/JF

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Jun 2012 13:09:51 -0400

Thanks. Added all except this one, where you and Senthil have 
conflicting opinions:

> +1 on a MUST here, as stated above. The MIB is needed for any serious

My two cents: I tend to agree with Senthil (even if both of us are 
authoring a CGN MIB draft). Not all CGN deployments need to be 
"serious". It does makes sense to recommend that implementers add SNMP 
support but some operators may not care about it, and it won't harm the 
Internet if they don't. So I added this justification:

"This requirement is at the SHOULD level to acocunt for the fact that 
some CGN operators may not need management functionality."

Simon