[Dime] FW: Martin Stiemerling's Discuss on draft-ietf-dime-nat-control-15: (with DISCUSS)

[shwethab <[e-mail]>]

Hello All,

As discussed at IETF83, draft-ietf-dime-nat-control-16 has been submitted to
address the open IESG DISCUSS. Additional Result-code to detect error as
brought up during the meeting has been added. Following is the summary of
the changes:

1. Conflicting configuration per endpoint due to multiple DNCA
NAT-controllers: When multiple NAT-controllers peer with a single NAT-device
it can receive conflicting NAT-configuration. Added clarification that there
will be a single NAT-controller and NAT-device for an endpoint.

2. Conflicting configuration per endpoint due to multiple protocols (SNMP,
PCP etc) deployed along with Diameter DNCA: Added a clarification that
NAT-device can have a configurable precedence among the protocols deployed
to control it. NAT-device MUST act based on this precedence and decide on
allowing/disallowing DNCA session establishment. Addition Result-code
MAX_BINDINGS_SET_FAILURE has been added.

3. NAT-device state w.r.t. DNCA sessions: When Diameter peer within the
NAT-device detects that Diameter peer within the NAT-controller is
unreachable or down for e.g. by  Device-watch-dog timeout, NAT-device state
pertaining to DNCA sessions established with that NAT-controller must be
cleared after a configurable grace period. If the DNCA diameter peer within
NAT-device crashes it is beyond the scope of DNCA protocol specification.
In addition, during IETF83 it was proposed to use session re-authorization
with Authorization-lifetime and Authorization-grace period AVP to handle
this case. Since per session reauthorization to detect peer failure in
NAT-controller will be an overkill, DWG timeout appears to be sufficient to
handle this case. 

Appreciate if you can review and provide comments if you object to any of
these changes.

Thanks,
Shwetha 


------ Forwarded Message
From: Martin Stiemerling <[e-mail]>
Date: Tue, 17 Apr 2012 11:33:01 +0200
To: Shwetha bhandari <[e-mail]>
Cc: The IESG <[e-mail]>, <[e-mail]>,
<[e-mail]>
Subject: Re: Martin Stiemerling's Discuss on draft-ietf-dime-nat-control-15:
(with DISCUSS)

Hi all,

On 04/11/2012 12:12 PM, shwethab wrote:
> Hi Martin,
>
> We are in the process of updating the draft and need your guidance, please
> find our comments/proposed update inline.
>
>
> On 3/29/12 7:33 PM, "Martin Stiemerling"<[e-mail]>
> wrote:
>
>> Martin Stiemerling has entered the following ballot position for
>> draft-ietf-dime-nat-control-15: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Referring to version -15 of the draft
>>
>> The below has been discussed with the authors and I'm waiting for an
>> update of the draft:
>>
>> What happens when the DNCA peer in the NAT device crashes. This seems to
>> be described at the end of Section 4.6
>>
>>     o  The DNCA Diameter peer within the NAT-device is unreachable or
>>        down and NCR fails to get a response.  Handling of this case
>>        depends on the actual service offering of the service provider.
>>        The service provider could for example choose to stop offering
>>        connectivity service.
>>
>> This is really weak from an operational view, i.e., a crashed DNCA peer
>> will leave 'zombie' NAT bindings in the device.
>>
>> Each installed binding does not have a timeout value after the binding is
>> automatically removed. At least I cannot find any timer in that respect.
>>
>> There is the "Event-Timestamp indicates the binding creation time.    If
>> NAT-Control-Binding-Status is set to Removed, Event-Timestamp indicates
>> the binding removal time"
>>
>> However, this is not a timer which takes care that bindings are
>> automatically removed, if nobody else is doing this.
>
> Agreed that NAT bindings should not continue to exist infinitely as a result
> of failure of Diameter peers. To resolve this we have to detect that the
> Diameter peers have failed and then have a mechanism to cleanup the NAT
> bindings.
> To detect the failure of the Diameter peers, we could:
> Option 1. Rely on Diameter watch dog  - Diameter protocol has a  inbuilt
> watchdog message exchange (RFC 3588 - Device-Watchdog-Request) that is a
> keep alive mechanism used by Diameter protocol.
> Option 2. Have an explicit keep alive between the DNCA peers. This was
> proposed at the DIME wg, using per session recurring periodic
> reauthorization.
> Option 2 seems to be a overkill, so after discussing with the DIME chairs we
> are planning to use Option 1 to detect failure of the peers either in NAT
> device or NAT-controller and take specific action, do you agree?

Option 1 is good, especially as it is reusing an existing mechanism.

>
> "When DNCA application on NAT device detects (using the above mechanism)
> that the NAT-controller application has failed, it will trigger clearing of
> all the NAT-bindings after a grace period that is configurable on the
> NAT-device. When DNCA application within NAT-controller detects failure of
> DNCA peer within NAT-device, it may try to reestablish DNCA sessions
> associated with that peer or disconnect corresponding access sessions."

The text is fine.

>
> To handle the case of DNCA peer within NAT-device having crashed, we plan to
> add the following text in Section 4.6 (Failure scenarios)
> "A discussion of the mechanisms how a NAT-device cleans up state in case the
> DNCA-peer on the NAT-device crashes is outside the scope of this document.
> Implementers of NAT-devices could choose from a variety of options such as
> coupling the state (e.g. NAT bindings) to timers which require periodic
> refresh, or time out otherwise, operating system watchdogs for applications,
> etc."

The text is fine.

>
> We also plan to update security-consideration with :
> " The operator also needs to consider security threats resulting from
> unplanned termination of the DNCA session.  Unplanned session termination,
> which could e.g. happen due to an attacker taking down the NAT-controller,
> leads to the NAT-device cleaning up the state associated with this session
> after a grace period.  If the grace period is set to zero, the endpoint will
> experience an immediate loss of connectivity to services reachable through
> the NAT-device following the termination of the DNCA session."
>
> We plan to add the above text into the revised ID if you agree.

The text is fine.

>
>>
>>
>>
>> Some other questions left open by this draft:
>> - What happens if a requested NAT binding is in conflict with an already
>> installed NAT binding or local configuration policy?
>
>
> We plan to add this text:
>      Operational considerations MAY require an operator to use
>      alternate control mechanisms or protocols such as SNMP or manual
>      configuration via a Command-Line-Interface to apply per-endpoint NAT-
>      specific configuration, like for example static NAT-bindings.  For
>      these cases, the NAT-device MUST allow the operator to configure a
>      policy how configuration conflicts are resolved.  Such a policy could
>      for example specify that manually configured NAT-bindings using the
>      Command-Line-Interface always take precedence over those configured
>      using DNCA.

The text is fine.

>
> If DNCA peer in NAT device requests the entity that manages the Binding
> within the NAT device to install a binding but fails due to a conflict, our
> draft specifies that it should return an error to the controller with an
> error code indicating (8.2.3.  Permanent Failures) -
>        BINDING_FAILURE (TBD.RCX)
>
>           DNCA indicates that the requested binding(s) could not be
>           installed.  For example: Requested ports are already in use.

The text is fine.

>
> We plan to add another error code as follows:
>
>    MAX_BINDINGS_SET_FAILURE (TBD.RCX)
>
>            The DNCA Diameter peer within the NAT-device indicates that it
>            failed to conform to a request to configure the maximum number
>            of bindings for a session.  For example: An operator defined
>            the maximum number of bindings on the NAT-device using a method
>            or protocol which takes precendence over DNCA.

The text is fine.

>
>> - Section 3.3,
>>    "This is to ensure that NAT-devices
>>     controlled by multiple NAT-controllers do not receive conflicting
>>     control requests for a particular endpoint, or would be unclear which
>>     NAT-controller to send accounting information to."
>>    But what happens if a DNCA NAT is receiving conflicting control
>> requests?
>> - what happens if DNCA has installed a binding which is also owned by
>> some other entity? This can happen, but the question is if what happens
>> with the NAT binding in the NAT itself, if the binding is removed from
>> DNCA? How are bindings differentiated?  Other approaches, such as SIMCO
>> and  the MIDCOM MIB introduce the onwership of the binding, allowing to
>> identify which agent is owning the binding. This allows also
>> implementations to have multiple owners for the same binding.
>> - How would you express such ownership?
>
>
> We plan to clarify this by adding following text:
> "From a DNCA perspective an operator MUST ensure that the session
> representing a particular endpoint is atomic."

Not perfect, since the protocol does not give any hint if something is
going wrong, but I can live with that. However, you cannot specific what
an operator is supposed to do, i.e., 'MUST' is not appropriate here.
You can only specify what the protocol must do.

>
>
> By specifying end point being controlled by a single DNCA controller it
> eliminates the cases where conflicting control messages can be received for
> the same endpoint from different controllers.
> All the control messages are received to be applied for a specific session
> representing an endpoint, hence control message for a given endpoint cannot
> conflict with control message for another. Conflicts can happen when an
> existing session is updated.
> For e.g.
> Maximum NAT bindings to be installed for an endpoint is a control message-
> This applies to a endpoint session, DNCA protocol handles update of this and
> specifies behavior when an update message changes already active value.
> Behavior and error codes are specified in 4.2.  Session Re-Authorization.
>
> If you are referring to Bindings of a given endpoint that may conflict with
> bindings to be installed for another endpoint session, we can add text in
> the draft to clarify that:
> "The endpoint identifier Framed-IP-Address and the internal address in
> NAT-Internal-Address specified to install NAT-bindings for the session MUST
> match."

Yes, this would be good.

>
> If the external address + port required to create a binding is in use we
> already have the Binding failure (BINDING_FAILURE error code)
>
> Ownership is expressed by the concept of DNCA session that is unique per
> endpoint b/n the NAT-controller and the NAT device. How this ownership is
> maintained by the NAT-device w.r.t NAT-binding is NAT-device implementation
> detail and API specification between DNCA application and entity that
> manages NAT binding within the NAT-device.

Ok.

>
> Thanks,
> Frank/Shwetha
>

I have not checked the spelling which is probably required here and there.

Please submit an updated draft and I will clear my discuss once the
draft is there.

Thanks,

   Martin

-- 
IETF Transport Area Director

[e-mail]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

------ End of Forwarded Message