Search This Blog

Wednesday, October 10, 2007

firewall-wizards Digest, Vol 18, Issue 5

Send firewall-wizards mailing list submissions to
firewall-wizards@listserv.icsalabs.com

To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com

You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."


Today's Topics:

1. Re: Nat Limitations? (Dave Piscitello)
2. Re: Nat Limitations? (Dale W. Carder)
3. Re: Nat Limitations? (jason@tacorp.com)


----------------------------------------------------------------------

Message: 1
Date: Tue, 09 Oct 2007 13:39:38 -0400
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Nat Limitations?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <470BBCDA.1090301@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"

Patrick's topology is very practical.

Also, you might consider using authenticating users through a proxy (or
firewall) for allowed services. Depending on the proxy you use, this
gives you additional granularity in policy definition, logging, and
perhaps even bandwidth management.


Darden, Patrick S. wrote:
>>From what you have said, I am guessing you want to do this:
>
> res hall 1 res hall 2 res hall 3....
> | | |
> \ | /
> huge central fwsm
> |
> |
> internet
>
> I am guessing you want to segment each res hall off using a single
> inclusive VLAN, then NAT it in a central switch or router. I think
> you should reconsider. Instead of NATing centrally, why not NAT on
> the edge? You can use multiple VLANs, one per res hall, and multiple
> NAT's.
>
> End result--further segmentation for better security, reduced load
> on your central switch or router (save the CPU for BGP and/or
> ACLs--and raw speed!)
>
> Individual concerns:
>
> 1. concurrent translations limitation. Not a problem with the above.
> 2. I weep for the RIAA. You don't have to help them. You just have
> to act in accordance with applicable laws. If they give you one of
> their John Doe warrants with a single IP address that they claim
> corresponds to one person, you can tell them to be more specific due
> to NAT. The burden lies on them.
> 3. The above topography would work better for rate limiting. Less
> people would be affected by one or two bandwidth hawgs.
> 4. Certain applications might well break. NAT tends to break UDP
> apps more than TCP. It also tends to interfere with servers. Your
> students will not be able to run servers as easily, except inside
> the residence halls.
>
> You might want to do this to one residence hall first to test it.
> There is no substitute for real-world testing--who knows what
> bizarre effects might occur.
>
> One problem you might not have considered is the move to IPv6. You
> should NOT invest this much time and effort into such a huge
> NAT infrastructure if you plan to move to IPv6 in the next 4 years.
>
> --p
>
>
> -----Original Message-----
> From: firewall-wizards-bounces@listserv.icsalabs.com
> [mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
> jason@tacorp.com
> Sent: Tuesday, October 09, 2007 9:03 AM
> To: Firewall Wizards Security Mailing List
> Subject: [fw-wiz] Nat Limitations?
>
>
> Hello,
>
> I'm interested in hearing some thoughts on a topology I'm considering in
> pursuing. On a mid sized college campus, we have the funding to
> physically segment the residence halls from the rest of the campus
> network. This is a huge win from a security perspective among other
> things. We've also begun using a separate provider for bandwidth. A
> long-term goal would be to hand the management of these buildings off to a
> company who can maintain it to reduce our headaches.
>
> So, in building it we want to make it as portable as possible. As such,
> NAT comes to mind so we don't have to re-number it if a different provider
> takes it. It also has a number of other advantages which I'm sure are
> well known.
>
> The problem is that I'm concerned about the number of translations that
> will happen in these buildings. Currently this part of the network is
> allocated a /19 and we estimate there are just over 4,000 residents.
>
> I see some of the pitfalls being:
>
> * The cisco FWSM is limited to 256K concurrent translations. That's only
> 64 per user. Bit-torrent is likely to slaughter that.
>
> * It's harder to handle RIAA complaints since everything comes from a
> different public address.
>
> * Rate limiting (packet shaping) is currently done at the ISP for these
> buildings. We'll have to move that inside (more $$) or do protocol
> shaping instead of by IP address.
>
> * Certain applications may break, etc.
>
> So my question is:
>
> Has anyone tried to NAT this many of a certain type of user?
>
> and
>
> Do the benefits outweight the caveats?
>
>
>
> Jason Mishka - "I'm like a Subway in a land of McDonalds..."
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave.vcf
Type: text/x-vcard
Size: 220 bytes
Desc: not available
Url : https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20071009/fbbb3835/attachment.vcf


------------------------------

Message: 2
Date: Tue, 09 Oct 2007 11:57:15 -0500
From: "Dale W. Carder" <dwcarder@doit.wisc.edu>
Subject: Re: [fw-wiz] Nat Limitations?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <A1F8ACD0-1957-4444-A9EA-EC6062AD90F7@doit.wisc.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

First off, you may want to check out a couple of "resnet"
mailing lists that exist. I think educause hosts one.

On Oct 9, 2007, at 8:03 AM, jason@tacorp.com wrote:
> So, in building it we want to make it as portable as possible. As
> such,
> NAT comes to mind so we don't have to re-number it if a different
> provider
> takes it.

You could also acquire globally routable provider-independent address
space and an AS number. Then you could peer w/ one or more isp's
as well.

> It also has a number of other advantages which I'm sure are
> well known.

And a number of disadvantages that are well known.

> * It's harder to handle RIAA complaints since everything comes from a
> different public address.

ONLY interact with the RIAA via their laywers talking to your
laywers. You are not their agent.

> * Rate limiting (packet shaping) is currently done at the ISP for
> these
> buildings. We'll have to move that inside (more $$) or do protocol
> shaping instead of by IP address.

I would recommend you do the rate limiting yourself. More $$
upfront, but you can depreciate hardware and save costs elsewhere.

> Do the benefits outweight the caveats?

My experience with our /17 of dorms is no.

Dale


------------------------------

Message: 3
Date: Tue, 9 Oct 2007 12:21:50 -0400 (EDT)
From: jason@tacorp.com
Subject: Re: [fw-wiz] Nat Limitations?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <20071009122043.R24145@phoenix.cnwr.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Yes, I've already considered pushing the NAT closer to the edge. However,
it appears that the machine we planned to use doesn't do nat - number of
cisco 4 k's.

Jason

On Tue, 9 Oct 2007, Darden, Patrick S. wrote:

>
>> From what you have said, I am guessing you want to do this:
>
> res hall 1 res hall 2 res hall 3....
> | | |
> \ | /
> huge central fwsm
> |
> |
> internet
>
> I am guessing you want to segment each res hall off using a single
> inclusive VLAN, then NAT it in a central switch or router. I think
> you should reconsider. Instead of NATing centrally, why not NAT on
> the edge? You can use multiple VLANs, one per res hall, and multiple
> NAT's.
>
> End result--further segmentation for better security, reduced load
> on your central switch or router (save the CPU for BGP and/or
> ACLs--and raw speed!)
>
> Individual concerns:
>
> 1. concurrent translations limitation. Not a problem with the above.
> 2. I weep for the RIAA. You don't have to help them. You just have
> to act in accordance with applicable laws. If they give you one of
> their John Doe warrants with a single IP address that they claim
> corresponds to one person, you can tell them to be more specific due
> to NAT. The burden lies on them.
> 3. The above topography would work better for rate limiting. Less
> people would be affected by one or two bandwidth hawgs.
> 4. Certain applications might well break. NAT tends to break UDP
> apps more than TCP. It also tends to interfere with servers. Your
> students will not be able to run servers as easily, except inside
> the residence halls.
>
> You might want to do this to one residence hall first to test it.
> There is no substitute for real-world testing--who knows what
> bizarre effects might occur.
>
> One problem you might not have considered is the move to IPv6. You
> should NOT invest this much time and effort into such a huge
> NAT infrastructure if you plan to move to IPv6 in the next 4 years.
>
> --p
>
>
> -----Original Message-----
> From: firewall-wizards-bounces@listserv.icsalabs.com
> [mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
> jason@tacorp.com
> Sent: Tuesday, October 09, 2007 9:03 AM
> To: Firewall Wizards Security Mailing List
> Subject: [fw-wiz] Nat Limitations?
>
>
> Hello,
>
> I'm interested in hearing some thoughts on a topology I'm considering in
> pursuing. On a mid sized college campus, we have the funding to
> physically segment the residence halls from the rest of the campus
> network. This is a huge win from a security perspective among other
> things. We've also begun using a separate provider for bandwidth. A
> long-term goal would be to hand the management of these buildings off to a
> company who can maintain it to reduce our headaches.
>
> So, in building it we want to make it as portable as possible. As such,
> NAT comes to mind so we don't have to re-number it if a different provider
> takes it. It also has a number of other advantages which I'm sure are
> well known.
>
> The problem is that I'm concerned about the number of translations that
> will happen in these buildings. Currently this part of the network is
> allocated a /19 and we estimate there are just over 4,000 residents.
>
> I see some of the pitfalls being:
>
> * The cisco FWSM is limited to 256K concurrent translations. That's only
> 64 per user. Bit-torrent is likely to slaughter that.
>
> * It's harder to handle RIAA complaints since everything comes from a
> different public address.
>
> * Rate limiting (packet shaping) is currently done at the ISP for these
> buildings. We'll have to move that inside (more $$) or do protocol
> shaping instead of by IP address.
>
> * Certain applications may break, etc.
>
> So my question is:
>
> Has anyone tried to NAT this many of a certain type of user?
>
> and
>
> Do the benefits outweight the caveats?
>
>
>
> Jason Mishka - "I'm like a Subway in a land of McDonalds..."
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
>


------------------------------

_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


End of firewall-wizards Digest, Vol 18, Issue 5
***********************************************

No comments: