Subject: Re: [BEHAVE] New Version Notification for draft-xu-behave-stateful-nat-standby-05

From: Xu Xiaohu <[email-masked]>
Date: Mon, 13 Sep 2010 14:51:09 +0800

Hi all,

An update version of draft-xu-behave-stateful-nat-standby is available at
http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-05.

The major change is
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-xu-behave-statefu
l-nat-standby-05.txt

Best wishes,
Xiaohu

-----邮件原件-----
发件人: IETF I-D Submission Tool [mailto:[email-masked]] 
发送时间: 2010年9月10日 15:03
收件人: [email-masked]
主题: New Version Notification for draft-xu-behave-stateful-nat-standby-05

A new version of I-D, draft-xu-behave-stateful-nat-standby-05.txt has been
successfully submitted by Xiaohu Xu and posted to the IETF repository.

Filename:	 draft-xu-behave-stateful-nat-standby
Revision:	 05
Title:		 Redundancy and Load Balancing Framework for Stateful
Network Address Translators (NAT)
Creation_date:	 2010-09-10
WG ID:		 Independent Submission
Number_of_pages: 15

Abstract:
This document defines a framework for ensuring redundancy and/or 
load balancing for stateful Network Address Translators (NAT), 
including NAT44, NAT64 and NAT46.

The IETF Secretariat.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 14 Sep 2010 19:40:59 -0700

I have submitted a new I-D on NAT logging.
http://www.ietf.org/id/draft-sivakumar-behave-nat-logging-00.txt

Thanks
Senthil

---

From: <[email-masked]>
Date: Wed, 15 Sep 2010 08:24:55 +0200

Dear Senthil,

Thank you for editing this I-D.

Some comments about the log tables you included in your I-D:

* the naming of the tables can be re-considered since the log events may not correspond to an actual NAT operation but to a binding assignment (e.g., assign a block of 64 ports when an incoming packets is received)

* the NAT44 table are not complete since in the context of DS-Lite NAT44, an IPv6 prefix should also be stored, for layer-2 aware NAT a MAC address should be logged, etc.

* In case port ranges are assigned instead of individual ports, I don't think there is a need to log the events where the port range has been released. What would be the usage of such information?

* Other events can be logged such as the following:
- Static ports quota
- Well Known ports
- Max of softwires (case of DS-Lite)
- etc.

* in case port ranges are assigned, the destination IP address may not be available.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Senthil Sivakumar (ssenthil)
Envoyé : mercredi 15 septembre 2010 04:41
À : behave
Objet : [BEHAVE] New I-D on NAT logging

Thanks
Senthil
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 15 Sep 2010 02:25:09 -0700

Hi Med,
Thanks for your comments. Please see inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:25 AM
To: Senthil Sivakumar (ssenthil); behave
Subject: RE: [BEHAVE] New I-D on NAT logging

Dear Senthil,

[Senthil] Ok. I am thinking this would be considered a different event that should be defined. This would be an event triggered by some control protocol (RADIUS, AAA, PCP) or a data packet.

[Senthil] Good point. Thanks.

[Senthil] It is upto the implementation to decide that. But I think the usage is two fold. It aids debugging in identify the completion of a transaction (allocation of a block of ports and releasing it). To identify the usage for any accounting purposes - the timestamps of allocation and release of block of ports could be used. 

[Senthil] Agree. I will incorporate the comments in the next rev.

Thanks
Senthil

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Senthil Sivakumar (ssenthil) Envoyé : mercredi 15 septembre 2010 04:41 À : behave Objet : [BEHAVE] New I-D on NAT logging

Thanks
Senthil

---

From: <[email-masked]>
Date: Wed, 15 Sep 2010 11:48:31 +0200

Dear Senthil, 

Some comments inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Senthil Sivakumar (ssenthil)
Envoyé : mercredi 15 septembre 2010 11:25
À : BOUCADAIR Mohamed NCPI/NAD/TIP; behave
Objet : Re: [BEHAVE] New I-D on NAT logging

Hi Med,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:25 AM
To: Senthil Sivakumar (ssenthil); behave
Subject: RE: [BEHAVE] New I-D on NAT logging

Dear Senthil,

Med: The assignment of the port block is not necessarily triggered by a control protocol; it can be done dynamically by the NAT implementation as part of its operation. The main claimed advantage of this mode for assigning port set vs. individual ones is to enhance the performance of the NAT. Of course, the perf considerations are out of scope of your I-D. 

Med: In fact several logs are required to be generated/maintained by a NAT implementation: logs for legal storage purposes, logs for enforced legal interception, logs for executed commands/configuration, etc. Depending on the type of log we are talking about, some information is not required. For instance, for legal storage purposes, I don't see a need to have the deletion timestamps since it can be deduced from other allocation records if the same port block is assigned to another user. IMHO, it would be useful of the I-D mentions that various types of logs are required and the tables are provided as examples but not all information are mandatory to be stored since this is implementation/configuration specific.   

Thanks
Senthil

Cheers,
Med

-----Message d'origine-----

Thanks
Senthil

---

From: Jacni Qin <[email-masked]>
Date: Wed, 15 Sep 2010 23:53:50 +0800

Hi Senthil,

Just one comment, please see below,

On Wed, Sep 15, 2010 at 5:25 PM, Senthil Sivakumar (ssenthil) <
[email-masked]> wrote:

> * the naming of the tables can be re-considered since the log events may
> not correspond to an actual NAT operation but to a binding assignment (e.g.,
> assign a block of 64 ports when an incoming packets is received)
>
> [Senthil] Ok. I am thinking this would be considered a different event that
> should be defined. This would be an event triggered by some control protocol
> (RADIUS, AAA, PCP) or a data packet.
>
> * the NAT44 table are not complete since in the context of DS-Lite NAT44,
> an IPv6 prefix should also be stored, for layer-2 aware NAT a MAC address
> should be logged, etc.
>

I see you mentioned "sourceIPv6address" at the beginning of section4.1,
while in the following example (192.168.16.1, ...) you missed it.
It is confusing about the NAT44 in the ID, do you mean the one for DS-Lite
which as Med said, needs IPv6 address for translation? Or you mean the
others? For the ones that too need special parameters additionally for
translation, you probably have to log these parameters.
A clarification maybe help. :-)

Cheers,
Jacni

> * In case port ranges are assigned instead of individual ports, I don't
> think there is a need to log the events where the port range has been
> released. What would be the usage of such information?
>
> [Senthil] It is upto the implementation to decide that. But I think the
> usage is two fold. It aids debugging in identify the completion of a
> transaction (allocation of a block of ports and releasing it). To identify
> the usage for any accounting purposes - the timestamps of allocation and
> release of block of ports could be used.
>
> De : [email-masked] [mailto:[email-masked]] De la part
> de Senthil Sivakumar (ssenthil) Envoyé : mercredi 15 septembre 2010 04:41 À
> : behave Objet : [BEHAVE] New I-D on NAT logging
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 16 Sep 2010 01:20:00 -0700

Please look for [Senthil2].
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 5:49 AM
To: Senthil Sivakumar (ssenthil); behave
Subject: RE: [BEHAVE] New I-D on NAT logging

Dear Senthil, 

Some comments inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Senthil Sivakumar (ssenthil) Envoyé : mercredi 15 septembre 2010 11:25 À : BOUCADAIR Mohamed NCPI/NAD/TIP; behave Objet : Re: [BEHAVE] New I-D on NAT logging

Hi Med,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 2:25 AM
To: Senthil Sivakumar (ssenthil); behave
Subject: RE: [BEHAVE] New I-D on NAT logging

Dear Senthil,

[Senthil2] I can some text around this to specify the different types of logging requirements - but the fields are specified in the draft for each event as mandatory or non-mandatory. So mandatory fields should be sent when such an event is logged. It is not like all fields are optional. The tables are not really examples, for instance, if a BIB entry is created and logged, all the fields specified in the table as mandatory should be logged. It basically revolves around the assumption that a NAT device maintaining a particular table/database is expected to have those fields.

Thanks
Senthil

Thanks
Senthil

Cheers,
Med

-----Message d'origine-----

Thanks
Senthil

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 16 Sep 2010 01:22:28 -0700

________________________________

From: Jacni Qin [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 11:54 AM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]; behave
Subject: Re: [BEHAVE] New I-D on NAT logging

Hi Senthil,

On Wed, Sep 15, 2010 at 5:25 PM, Senthil Sivakumar (ssenthil) <[email-masked]> wrote:

	Hi Med,

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Wednesday, September 15, 2010 2:25 AM
	To: Senthil Sivakumar (ssenthil); behave
	Subject: RE: [BEHAVE] New I-D on NAT logging
	
	Dear Senthil,

	

I see you mentioned "sourceIPv6address" at the beginning of section4.1, while in the following example (192.168.16.1, ...) you missed it.
It is confusing about the NAT44 in the ID, do you mean the one for DS-Lite which as Med said, needs IPv6 address for translation? Or you mean the others? For the ones that too need special parameters additionally for translation, you probably have to log these parameters. 
A clarification maybe help. :-) 
 
Correct - I missed that, it should have said sourceIPv4Address (as it is a classic NAT44 log).  I will correct it in the next rev.

Cheers,
Jacni

	

	Thanks
	Senthil

	Cheers,
	Med

	-----Message d'origine-----

	Thanks
	Senthil

---

From: "Ramji Vaithianathan (rvaithia)" <[email-masked]>
Date: Thu, 16 Sep 2010 02:20:19 -0700

Hi,

Currently there are 2 set of events:

 1. BIB create and delete
 2. Session create and delete

As I see sessions that correspond to the same BIB have the same
(source_ip, post_nat_source_ip, protocol, source_transport,
post_nat_transport_port) values.  Is it possible to have a 32 bit BIB id
that is sent along with the first BIB create and for sessions associated
with this BIB use the BIB id instead of again sending source_ip, source
port etc.  This will reduce the size of the logging messages and
storing.

Thanks,

Ramji

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Senthil Sivakumar (ssenthil)
Sent: Wednesday, September 15, 2010 8:11 AM
To: behave
Subject: [BEHAVE] New I-D on NAT logging

Thanks
Senthil

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 16 Sep 2010 07:57:04 -0700

It is possible to do that, but I consider that an optimization and hence
would rather not address that in this draft. That said, there is also an
issue that would have to addressed which is that there could be multiple
NAT devices that an analyzer is receiving its data from. So it would
have to identify or correlate the BIB ID along with the source so that
they don't get messed up. But that is an implementation detail. 

Thanks
Senthil 

-----Original Message-----
From: Ramji Vaithianathan (rvaithia) 
Sent: Thursday, September 16, 2010 5:20 AM
To: Senthil Sivakumar (ssenthil)
Cc: behave
Subject: RE: [BEHAVE] New I-D on NAT logging

Hi,

 1. BIB create and delete

Thanks,

Ramji

-----Original Message-----

Thanks
Senthil