Subject: Re: [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)

From: David Harrington <[email-masked]>
Date: Thu, 19 Jul 2012 12:24:08 -0400

Hi,

(I restricted this response to behave wg, since that is where
lsn-requirements is chartered, not pcp wg; I added [email-masked] since
this is about a DISCUSS relating to ietf consensus).

I think we should mandate something if interoperability will break if it
is not done.
But if the port-control aspect can be achieved using proprietary protocols
with no impact on cgn operations, then a specific protocol should not be
mandated.

-- REQUIREMENTS for COMPLIANCE --

I frequently refer to the logic in the "Strong Security" BCP (RFC3365),
which makes a distinction between what MUST be implemented in a compliant
implementation, and what SHOULD be used by operators for interoperability
between network elements.
If an operator wants to set up a lsn-requirements-compliant CGN in a
multi-vendor environment, will it be problematic if vendor A uses A-style
port control, vendor B uses B-style port control, vendor C uses PCP,
vendor D uses MIDCOM-MIB, and vendor E uses Diameter NAT control?
If so, then there would seem to be justification to specify that **to be
compliant to the IETF lsn-requirements standard/BCP/InformationalRFC
recommendation** PCP MUST be implemented, so it is AVAILABLE if an
operator chooses to use it. If implementers don't implement it in product,
it won't be there for operators to use to achieve interoperability. Of
course, a similar argument might justify also requiring implementation of
Diameter NAT control and the MIDCOM-MIB.

Do we want to require one specific standard as THE solution required to be
compliant to this lsn-requirements standard, or do we want to provide a
toolkit of multiple must-implement standards plus advice about how to
combine them, and a deployer gets to choose which to use together, or do
we want to specify a toolkit of implementation-optional standards that
might be available and a deployer needs to figure out how to make the
available options work together?

Requiring PCP for compliance does not mean a vendor is required to
implement PCP, any more than a vendor is required to implement BGP, but if
a vendor claims to be BGP compliant, then there are aspects of BGP, or
other standards that BGP relies upon being present, that MUST be there. If
an implementer wants to claim compliance to the NAT-MIB, they MUST also
implement ifIndex (and presumably SNMP to access the MIB).
If a vendor claims to be compliant to the lsn-requirements standard (or
BCP or Informational RFCXXXX) then they MUST implement those aspects that
are required for compliance.

Now, in the security world, where security is a system-wide process, if
using multiple algorithms can create hard-to-detect security holes, there
is strong justification for REQUIRING specific protocols be used across
devices/vendors to avoid introducing such holes into the system. And, in
the security world, there is a whole community of attackers looking for
those holes so they can take advantage of such weaknesses in the overall
security system.

If CGN interoperability is not significantly impacted by having multiple
types of port forwarding or other middlebox algorithms rather than a
single algorithm, other than extra work for operators, then we probably
should not REQUIRE, but simply RECOMMEND a standards-based solution such
as PCP. We should NOT require it just because we want to see vendors use
our protocols; that is a market-driven decision to be made by vendors
based on customer demand.

--
David Harrington
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

On 7/19/12 8:51 AM, "Simon Perreault" <[email-masked]> wrote:

>Behaviers, PCPers,
>
>During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was
>filed regarding the PCP requirement. Details below.
>
>I think this DISCUSS needs to be discussed. So please discuss.
>
>Please reply to [email-masked].
>
>Thanks,
>Simon
>
>
>-------- Message original --------
>Sujet: Re: Martin Stiemerling's Discuss on
>draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
>Date : Thu, 19 Jul 2012 10:46:42 +0200
>De : Martin Stiemerling <[email-masked]>
>Pour : Simon Perreault <[email-masked]>
>Copie à : The IESG <[email-masked]>, <[email-masked]>,
><[email-masked]>
>
>Hi Simon, all,
>
>On 07/17/2012 11:11 PM, Simon Perreault wrote:
>> Le 2012-07-17 16:42, Martin Stiemerling a écrit :
>>>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll
>>>> fix the text in a later revision.
>>>
>>> Can we mandate a specific protocol to be used for this or can we only
>>> mandate that such a type of protocol is being used? I don't see the
>>>IETF
>>> in the position to mandate this type of protocol for CGNs.
>>>
>>> There are other protocols out there which might be suitable. Note that
>>>I
>>> am co-author of some, but this isn't the reason for the question. I do
>>> not get any reward if I promote these protocols.
>>>
>>> It is more:
>>> do we need to constrain CGN deployments to a protocol (PCP) which is
>>> developed right now, or are we open to existing or future protocols, or
>>> whatever folks deploying this deem right?
>>>
>>> I would propose to change REQ-9 to :
>>> REQ-9: A CGN MUST include a middlebox control protocol that allows
>>> manipulation of CGN bindings with the following contstraints <list
>>>items
>>> A and B>
>>> REQ-9a: If PCP is used these contstraints MUST be applied in addition
>>>to
>>> contraints A and B:
>>> <list items C and D>
>>
>> That was discussed in IETF 81 (Québec). Here's the extract from the
>> minutes:
>>
>>            Stuart Cheshire: ietf has one port forwarding protocol, which
>>            is PCP, so we should require it by name
>
>There are multiple middlebox control protocols published by the IETF
>(standards track and experimental) and I have not seen any call for
>consensus on what **the** IETF's middlebox control is, neither I have
>seen any RFC that states this.
>
>I do not see that an individual can declare IETF consensus based on his
>own opinion.
>
>
>>
>>            Dave Thaler: I agree. PCP doc is in final stages.
>
>Again, an opinion of an individual. Nothing wrong about it, but it does
>not state IETF consensus.
>
>>
>> There was consensus from the WG. In consequence, the text was changed
>> from this (-02):
>>
>>              A CGN SHOULD support a port forwarding protocol such as the
>>              Port Control Protocol [I-D.ietf-pcp-base].
>>
>> to this (-03):
>>
>>             A CGN SHOULD include a Port Control Protocol server
>>             [I-D.ietf-pcp-base].
>>
>> (That requirement later became a MUST, but that's orthogonal to what
>> protocol we require.)
>
>I do not see that the IETF can mandate what protocols are being used to
>control a device. The market will decide!
>
>For instance, the is no MUST required that routers implement BGP. It is
>good to do this, but if one decides to go for IS-IS (or whatever) that
>is just fine.
>
>Another example, there is also no MUST requirement that routers, or
>hosts in general, have to implement SNMP.
>
>However, I can see the immediate need to mandate that a CGN SHOULD/MUST
>support a middlebox control protocol that is able to install and
>maintain NAT bindings.
>
>   Martin
>
>-- 
>[email-masked]
>
>NEC Laboratories Europe - Network Research Division NEC Europe Limited
>Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>Registered in England 283
>
>
>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

---

From: David Harrington <[email-masked]>
Date: Thu, 19 Jul 2012 12:37:55 -0400

-- BCP or not? --

As previously-responsible AD for behave, I have had serious concerns about
this document being published as a BCP.

In another email, I discussed whether PCP should be required to be
compliant to this BCP.

I think the IETF needs to decide whether lsn-requirements is something to
be compliant to. The title and BCP status seem rather misleading, in my
opinion. 
Following RFC3365, MUST is for implementers; SHOULD is for deployers. If
we want to require vendors to implement specific features in a manner
COMPLIANT to this specification, then this really should be a standard,
not a BCP. 
If we want to standardize implementation behaviors, then I think this
should be an explicit standard, not some other type of RFC that will
implicitly be a standard but with possibly less scrutiny than an explicit
standard would generate.

A BCP often carries similar weight to a standard, and I question whether
some of these requirements are best CURRENT practice, especially if PCP is
a MUST. It might be best DESIRED practice, or best RECOMMENDED practice,
but I doubt some of these requirements are best CURRENT practice. If we
simply want to document what some existing deployments are doing, then I
think an Applicability statement or an Informational RFC might be more
appropriate than a BCP. I think this should be a BCP only if there is a
strong consensus that this is the way deployments SHOULD be done, based on
actual deployment experience by a variety of operators using current
implementations - that would represent best CURRENT practices.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 19 Jul 2012 17:12:03 +0000

Good point, some data in this regards:

All previous behave RFCs that 'standardized' NAT behavior are BCPs
(RFC4787, 5508, etc).

And they are have lots of MUSTs