Subject: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt

From: Maglione Roberta <[email-masked]>
Date: Fri, 26 Aug 2011 14:56:50 +0200

Hello,
  I have a question about section 5. Bulk Port Allocation:

I understand this section discusses about the impacts of allocating multiple ports, but why there is no requirement in the document talking about Bulk Port Allocation?

In my opinion it would be useful to add in section 3 at least a simple requirement about Bulk Port Allocation, for example something like:

REQ-XX: The CGN MUST support Bulk Port Allocation. The port set allocated by the CGN can be Consecutive or Scattered.

Comments?

Thanks,
Best regards,
Roberta

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 15:20:54 +0200

Hi Reberta,

FYI, this point was discussed in this thread: http://www.ietf.org/mail-archive/web/behave/current/msg09300.html.

I still support the idea of having an explicit requirement to support the port set mode.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Maglione Roberta
Envoyé : vendredi 26 août 2011 14:57
À : [email-masked]'
Objet : [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt

Hello,

Comments?

Thanks,
Best regards,
Roberta

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 27 Aug 2011 08:31:42 +0200 (CEST)

> REQ-XX: The CGN MUST support Bulk Port Allocation. The port set allocated by the CGN can be Consecutive or Scattered.

I support making it a MUST requirement, due to the fact that without it, 
it's nearly impossible to handle the logging load.

I also feel that support for both consecutive and scattered must be 
supported.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Wed, 31 Aug 2011 10:27:17 -0400

Mikael Abrahamsson wrote, on 08/27/2011 02:31 AM:
> I support making it a MUST requirement, due to the fact that without it, it's
> nearly impossible to handle the logging load.

According to previous calculations, the logging load is not unmanageable.
See <http://www.ietf.org/mail-archive/web/behave/current/msg08801.html>.

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, 31 Aug 2011 10:32:06 -0400

Maglione Roberta wrote, on 08/26/2011 08:56 AM:
> In my opinion it would be useful to add in section 3 at least a simple
> requirement about Bulk Port Allocation, for example something like:
> 

As the document editor, I need rationale text for this proposed requirement. I
think the best way forward to suggest a new requirement would be to send
proposed rationale text to the mailing list so as to reach a consensus that I
can edit into the document. Otherwise I have nothing to work with, and I'll have
to request WGLC from the chairs.

Simon

---

From: [email-masked]
Date: Wed, 31 Aug 2011 13:36:39 -0400

> See <http://www.ietf.org/mail-archive/web/behave/current/msg08801.html>.

+1 on the MUST here. 

>From an operator perspective, logging is barely manageable, if not 
unmanageable at all, 
without bulk/range/block allocation. It could be managed, but at a very 
high cost both 
for the logging systems and its operations. 

The rationale here is that in many countries, law enforcement agencies 
mandate to keep
these logs for at least a year, sometimes even longer. With the numbers 
you refered
to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year 
*per CGN device*.
And this is only storing, we haven't discussed the operational nightmare 
of filtering, 
searching and reporting on this data. 

/JF

---

From: Simon Perreault <[email-masked]>
Date: Wed, 31 Aug 2011 14:00:10 -0400

[email-masked] wrote, on 08/31/2011 01:36 PM:
> The rationale here is that in many countries, law enforcement agencies mandate
> to keep
> these logs for at least a year, sometimes even longer.

Not disagreeing with you, but I fear that this rationale would go against RFC2804:

   The IETF has decided not to consider requirements for wiretapping as
   part of the process for creating and maintaining IETF standards.

I feel like it would make a stronger rationale if we focus on other advantages
of bulk port allocation...

> With the numbers you refered
> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN
> device*.

That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth
of external ports consumed per second. That's a really big NAT!

Simon

---

From: [email-masked]
Date: Wed, 31 Aug 2011 14:41:11 -0400

>> The rationale here is that in many countries, law enforcement agencies 
mandate
>> to keep these logs for at least a year, sometimes even longer.

Good point. The definition of wiretapping in RFC2804 is wide enough that 
logging
source ports is probably (barely) included in this context. 

Other advantages would be interesting, but I can't see any other reason to 
keep 
logs on the long term besides heating a building with spinning hard 
drives. 

>> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year 
*per CGN
> of external ports consumed per second. That's a really big NAT!

Of course, but even if logging is an order of magnitude smaller, this is 
only one 
NAT box in a network presumably using several CGNs. CGN is, by definition, 

a really big NAT. Logging without port ranges remains a non-trivial an 
operational problem. 

/JF

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Sep 2011 07:06:46 +0200 (CEST)

> See <http://www.ietf.org/mail-archive/web/behave/current/msg08801.html>.

There are markets where there is either already a requirement, or talk 
about putting into law a requirement to save such data for 3 years. When 
one is talking about many tens of gigabits/s of traffic we're talking 
really serious storage systems (hundreds of terabytes if not thousands 
of terabytes of storage).

Avoiding logging any kind of destination information is to be preferred, 
only logging the source port range being made available for the customer 
and requiring the party wanting information to supply time,IP address and 
port to track an individual user, makes the logging load go down by factor 
1000 or more in our calculations.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Sep 2011 07:11:24 +0200 (CEST)

On Wed, 31 Aug 2011, [email-masked] wrote:

> Other advantages would be interesting, but I can't see any other reason 
> to keep logs on the long term besides heating a building with spinning 
> hard drives.

Well, I'd say being a good netizen and being able to do regular abuse 
tracking, means one often wants to save logs for months anyway. Creating a 
logging system to handle the rate of data being creating by flow export 
costs more to aquire than the CGN device itself when we looked into it.

A lot of ISPs do not log this today so they can't really do abuse tracking 
at all.