Subject: [BEHAVE] CGN REQ: SPAM Protection

From: <[email-masked]>
Date: Tue, 15 Mar 2011 15:55:46 +0100

Re-,

An explicit requirement about the support of means to protect against SPAM should be IMO added to the req list. For instance the default behaviour would be the CGN block port 25 for SMTP.

Cheers,
Med

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 10:53:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, March 15, 2011 7:56 AM
> To: [email-masked]
> Cc: 'behave' <([email-masked])>
> Subject: [BEHAVE] CGN REQ: SPAM Protection
> 
> Re-,
> 
> An explicit requirement about the support of means to protect against
> SPAM should be IMO added to the req list. For instance the default
> behaviour would be the CGN block port 25 for SMTP.

That is an operational policy of an ISP, not a CGN.  

Does IETF have any existing recommendation to block outbound TCP/25?  If
not, I don't believe we could create one in BEHAVE.

-d

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 19:08:21 +0100

Re-,

Port 25 is provided as an example.
The functional requirement can be reworded to something like: "the CGN SHOULD be able to block some ports. The ports to be prohibited MUST be configurable." 

Please don"t forget the CGN we are talking about can be a DS-Lite CGN: the CGN  is the place to access the IPv4 packet. "Legacy" filters to prevent SPAM as deployed in operational networks are not able to inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN. 

Cheers,
Med

________________________________________
De : Dan Wing [[email-masked]]
Date d'envoi : mardi 15 mars 2011 18:53
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] CGN REQ: SPAM Protection

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 11:15:48 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 11:08 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: RE : [BEHAVE] CGN REQ: SPAM Protection
> 
> Re-,
> 
> The functional requirement can be reworded to something like: "the CGN
> SHOULD be able to block some ports. The ports to be prohibited MUST be
> configurable."
> 
> Please don"t forget the CGN we are talking about can be a DS-Lite CGN:
> the CGN  is the place to access the IPv4 packet. "Legacy" filters to
> prevent SPAM as deployed in operational networks are not able to
> inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN.

I don't see this being a CGN requirement.  I assume you want these
ports blocked before they consume state in the CGN, which means they
are blocked in *front* of the CGN function.  In the AFTR architecture,
it's somewhere between where the tunnel is unwrapped and the packets
are NATted.  Is that "in" the CGN?  

Maybe Softwires should take on that requirment?  Or are there
non-DS-Lite scenarios where this is really something that only
the CGN can do?

-d

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Mar 2011 14:51:03 -0400

I would agree with dan.
What you are describing is a firewalling or filtering function.  While 
those are functions operators want, those are not the function of the 
CGN.  Divide a problem a conquering the pieces serves us well.

Yours,
Joel

On 3/15/2011 2:15 PM, Dan Wing wrote:
>>> Cc: 'behave'<([email-masked])>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 10:01:07 +0100

Re-,

Please see inline.

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 19:16
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] CGN REQ: SPAM Protection

I don't see this being a CGN requirement.  I assume you want these
ports blocked before they consume state in the CGN, which means they
are blocked in *front* of the CGN function.

Med: Exactly.

  In the AFTR architecture,
it's somewhere between where the tunnel is unwrapped and the packets
are NATted.  Is that "in" the CGN? 

Med: It is an input to the NAT function of the CGN: "don't NAT when internal source port is equal to X" 

Med: I prefer to have this discussed in the CGN requirement. The CGN I-D should not be specific to given model (e.g., NAT444, DS-Lite, L2-NAT).

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 10:02:47 +0100

Dear Joel,

This is a filtering function which can be seen in the same level as  the "filtering behavior" defined by BEHAVE WG in the past.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Joel M. Halpern
Envoyé : mardi 15 mars 2011 19:51
Cc : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: SPAM Protection

I would agree with dan.

Yours,
Joel

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 09:41:46 -0400

> This is a filtering function which can be seen in the same level as  the "filtering behavior" defined by BEHAVE WG in the past.

Why should we require this of a CGN when we don't require it of a plain
router?

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: <[email-masked]>
Date: Wed, 16 Mar 2011 15:12:31 +0100

Dear Simon,

Please see inline.

Cheers
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 16 mars 2011 14:42
À : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: SPAM Protection

Med: IP routers does not inspect the port information; the CGN does.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 15:47:05 +0100

In your previous mail you wrote:

   Med: Exactly.
   
=> I am afraid there is some misunderstanding: IMHO Dan meant
this function is not required to be implemented inside the CGN but
can (and IMHO should) be implemented in a device placed before
the CGN in the path between the client and the CGN, for instance
in front of the CGN.

Regards

[email-masked]

PS: IMHO it should be as close as possible to the client.
Note my ISP puts it in the ISP-provided home gateway
(there is a flag to enable port 25 and its default is disabled,
i.e., exactly what I'd like :-).

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 15:50:47 +0100

This is a filtering function which can be seen in the same level as  the 
   "filtering behavior" defined by BEHAVE WG in the past.
   
=> deeply disagree: Joel is right: this function is not a natural part
of the NAT one.

Regards

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 15:53:56 +0100

Re-,

We are not defining a "natural" NAT, we are dealing with a NAT to be deployed in providers networks: i.e., new requirements are to be taken into account.

Enforcing filtering on internal ports has a value for us as SPs.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mercredi 16 mars 2011 15:51
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Joel M. Halpern; [email-masked]
Objet : Re: [BEHAVE] CGN REQ: SPAM Protection

   

Regards

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Mar 2011 11:38:05 -0400

The firweall function should not be conflated with the CGN function.
For NAT44, there is some inherent conflating due to the constraint 
imposed by port rewriting / port acceptance issues.
With NPT66, there is no such port rewriting.  As such, there is no need 
to couple the two functions.  The firewall may happen to be in the same 
device as the NPT.  It can be upstream or downstream of that, depending 
upon where the operators wants to place it.

Yours,
Joel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 08:40:44 -0700

> Sent: Wednesday, March 16, 2011 2:01 AM
> Subject: RE: [BEHAVE] CGN REQ: SPAM Protection
> 
> Re-,
> 
> Please see inline.
> 
> 

? When the *internal* (source port) is X?

> Med: I prefer to have this discussed in the CGN requirement. The CGN I-
> D should not be specific to given model (e.g., NAT444, DS-Lite, L2-
> NAT). =

-d

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Mar 2011 12:24:33 -0400

This note may have looked a little confused.
The point is that as much as possible, we should treat firewall and NAT 
separately.
The paradigmatic example is from another very similar thread, on NPT66. 
  There it can be truly separate.
It seems to me that even for a CGN NAT44, treating them as separate will 
work better.

Yours,
Joel

On 3/16/2011 11:38 AM, Joel M. Halpern wrote:
>> This is a filtering function which can be seen in the same level as
>> the "filtering behavior" defined by BEHAVE WG in the past.
>>
>> Cheers,
>> Med
>>

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 07:20:28 +0100

Hi Dan,

Please see inline.

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 16:41
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] CGN REQ: SPAM Protection

Med: I used "internal" to precise this rule is to be enforced on packets received on the customer-facing interface.

-d

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 07:27:56 +0100

Dear Joel,

I see your point. 

The issue I have is that firewalls are defined no where...and in the meantime I need a function which filters the internal ports before enforcing the NAT operation. I package this as a CGN function.

FWIW, we are not requesting for specific NAT mapping filtering behaviour since we are recommending the EIM/EIF; which is advocating for "transparent" NAT.

Cheers,
Med

-----Message d'origine-----
De : Joel M. Halpern [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 17:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: SPAM Protection

Yours,
Joel

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Mar 2011 16:29:52 +0100

The issue I have is that firewalls are defined no where...and in
   the meantime I need a function which filters the internal ports
   before enforcing the NAT operation. I package this as a CGN
   function.
   
=> I disagree: the only relationship between firewalls and CGNs
should be that a firewall should be placed in front of a CGN
(i.e., filtering before translation).

Regards

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 17 Mar 2011 11:48:40 -0700

> (i.e., filtering before translation).

Careful.  I do not believe we should be using the word "should" and
"firewall" .  How about "may" and "security enforcement point".  That
said, i would highly discourage any design or standard that has
stateful middle-boxes in series.

Cameron

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Mar 2011 19:27:44 -0400

> (i.e., filtering before translation).

Ok so what I understand from this thread, and with input from the chairs'
guidelines about what should be the scope of this draft, is that we should only
document filtering that is specific to CGN devices. If it can be done elsewhere
in the network, then it's out of scope. Furthermore, NAT-specific filtering is
already documented in the BEHAVE RFCs. If there's more to be said about
NAT-specific filtering, then it means that an update of these RFCs would be
required. It really needs to be specific to CGNs to be in scope for this draft.
And so far, as editor, I haven't seen consensus on any CGN-specific filtering.

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Mar 2011 17:11:47 +0100

In fact there are two things:
 - filtering which is builtin in a NAT or an AFTR
 - extra filtering which is usually performed by a firewall
the issue with the second is a firewall is not an IETF object, i.e.,
there is no good RFC to refer to...

Regards

PS: IMHO despite of this issue CGN REQs should not include firewall stuff
(but as I said some days ago to deny a problem doesn't solve it :-).

---

From: <[email-masked]>
Date: Sun, 27 Mar 2011 13:55:02 +0200

Hi Francis, all,

There is no I-D which defines what is a firewall...

Ingress filtering is needed to meet some provider-specific needs: this includes filtering internal port, internal IP address, NAT filtering, etc.

Please don't focus on the "N" and forget "CG".

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : samedi 26 mars 2011 17:12
À : Simon Perreault
Cc : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: SPAM Protection

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 27 Mar 2011 14:23:44 +0200

=> I know and this is the reason I don't say your problem should not be
addressed. But this is not in the scope of BEHAVE too (and seeing
what BEHAVE did for NATs I really prefer this will be never handled
by BEHAVE :-).

I have an idea: as it is something looking for a place to be done,
you should ask during the technical plenary where should be the place
(including the area). You could get an IAB/IESG bless decision...
   
Regards