Re: Requirements for IPv6 Firewalls

[Peter Kristolaitis]

On 4/18/2014 11:29 PM, Jeff Kell wrote:
Anyone ever pentested you? It's an enlightening experience. Jeff 


At a previous job, we hired a company (with CISSP-certified pentesters) 
to do a black box pentest of our network.


Things I was "enlightened" by:

- It's OK to work in a highly technical field with no technical 
background.  The pentester they sent couldn't get Backtrack running on 
the machine we had provided to him because the onboard video didn't 
support 32-bit color under Linux (IIRC, a P4-era Dell desktop).  The 
concept of reading log files to find out what was wrong was completely 
foreign to him, as was the required 1-line fix in the X11 config.


- It's OK to not report a horribly insecure box to the client if you're 
stupid or lazy.  We had set up a honeypot box on our network to see if 
the pentester would find it, and despite tons of log evidence showing 
that he both found the box and the weak services... no mention of it was 
made on the report submitted to us.  Needless to say, this made the 
entire report suspect, and my boss had great pleasure in yelling at the 
vendor when I brought it to her attention.


- It's OK to not know anything at all about the tools you're using to do 
the job.  The pentester called us because he was getting "weird nmap 
results" and couldn't grok them (and insisted that we had given him the 
wrong IP addresses).  The reason?  A firewall that dropped unwanted 
traffic.  Seriously.  CISSP certified and he couldn't figure out how to 
detect firewalls that have a default-drop policy.


- It's OK to rely only on automated tools and blindly trust their 
output.   No attempts at targeted attacks were made, despite being 
specifically asked and authorized to do destructive testing against our 
test servers.  We KNEW from our own testing that there were some SQL 
injection and buffer overflow holes there (again, some even placed on 
purpose to see what he'd find), and his automated tools didn't find them 
so he assumed everything was fine.


And that's just SOME of the stuff from that particular experience. 
Enlightening?  Yes.  I now do my own pentesting, because I'd rather not 
waste $20K+ on a report of questionable quality done by someone who may 
or may not know how to run nmap, let alone more technical 
application-level attacks.


There are undoubtedly some good pen-testers out there that are worth 
every dime they charge.  However, like every other technical speciality, 
there are a LOT of really, really, really terrible practitioners.
Shelling out big money to hopefully find the former in a field of mostly 
the latter is bound to be an exercise in both frustration and misspent 
resources.

Re: Requirements for IPv6 Firewalls

[Jimmy Hess]

On Fri, Apr 18, 2014 at 10:02 AM, William Herrin  wrote:

It would appear point (5)  in favor of NAT with IPv6 is the only point
that has any merit there.   (1) to (4) are just rationalizations.
None of (1) to (4) are the reasons IPv4 got NAT, none are valid, and
none are good reasons to bring NAT to IPv6  or use NAT in designs of
IPv6 networks.

You could also add as good reasons..   (6) Requirement for NAT based
on personal preference,  and...

(7) "You don't need this NAT function anymore,"  is not a good reason
to 'withhold the feature as a design and implementation option'.  --
"IPv6 is clearly not as mature as IPv4, when my IPv4 router has
greater flexibility in translation options"
---

(1) to (4) are just excuses for people who want NAT to not admit the
real reasons which are illogical,  BUT  still important.

 (5) is quite valid.   Also, you  cannot fight it.   When you have
customers  that demand NAT, even though there is absolutely no sound
reason for NAT anymore. The users will still buy whatever gives
them the feature they deemed important,  based on their experience
with IPv4.


The fact of the matter is,  the demand has irrational sources
contributing:  comfort and change-aversity  and loss-aversity.

People want to keep and not lose their IPv4 or their IPv4 features.
They expect to cherrypick IPv6's advantages   and not lose any
functionality from V4 or have any extra work to do,  or re-thinking of
their understanding of IP networking to be doing.

So if you are building IPv6 firewall SW,  you should definitely
include any NAT functionality  you believe that many of your potential
customers will demand.

The fact is...  as a product vendor to move the maximal number of
people to the IPv6 paradigm: you are still going to have to cater to
people with IPv4-like thinking.

Therefore...  I fully expect all the NAT features of IPv4  to have an
IPv6 equivalent appearing.


> 1. Easier to manage the network if the IPv4 and IPv6 versions are [...]
> 2. Risk management - developing a new operating posture for a new [...]
> 3. Renumbering - works about as well in IPv6 as in IPv4, which is to [...]
> 4. Defense in depth is a core principle of all security, network and [...]
5.
> Feel free to refute all four points. No doubt you have arguments you
> personally find compelling. Your arguments will fall on deaf ears. At
> best the arguments propose theory that runs contrary to decades of
> many folks' experience. More likely the arguments are simply wrong.

--
-JH

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 19, 2014, at 10:29 AM, Jeff Kell  wrote:

> I call BS...

You can 'call' it all you like - but people who actually want to keep their 
servers up and running don't put stateful firewalls in front of them, because 
it's very easy to knock them over due to state exhaustion.  In fact, it's far 
easier to knock them over than to knock over properly-tuned naked hosts.

Also, you might want to search the NANOG email archive on this topic.  There's 
lots of previous discussion, which boils down to the fact that serious 
organizations running serious applications/services don't put stateful 
firewalls (or 'IPS', or NATs, et. al.) in front of their servers.

The only way to secure hosts/applications/service against compromise is via 
those hosts/applications/services themselves.  Inserting stateful middleboxes 
doesn't actually accomplish anything to enhance confidentiality and integrity, 
actually increases the attack surface due to middlebox exploits (read the 
numerous security notices for various commercial and open-source stateful 
firewalls for compromise exploits), and has a negative impact on availability.

Again, take a look at this preso:



And take a look at pp. 17-18 of this preso:



I've seen 3mb/sec of spoofed SYN-flooding take down a supposedly 20gb/sec 
stateful firewall due to state exhaustion in about 2 minutes; I've seen 6kpps 
of HOIC take down a supposedly 10gb/sec load-balancer due to state-table 
exhaustion in 60 seconds.  Each of those devices required an ~30-minute hard 
reboot - and those are just two of too many examples to keep track of, heh.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Jeff Kell]

On 4/18/2014 10:10 PM, Dobbins, Roland wrote:
> On Apr 19, 2014, at 9:04 AM, Jeff Kell  wrote:
>
>> It's how we provide access control.
> Firewalls <> 'access control'.
>
> Firewalls are one (generally, very poor and grossly misused) way of providing 
> access control.  They're often wedged in where stateless ACLs in 
> hardware-based routers and/or layer-3 switches would do a much better job, 
> such as in front of servers:

I call BS...  what do you expect closes the gap, host firewalls?  Most
3rd party crap has no firewalls and gets no specific rules for local
LANs or authorized users.

Firewalls are front-line defense, for the crap that is too generic /
misconfigured to protect itself.  And there are tons of these.

Anyone ever pentested you?  It's an enlightening experience.

Jeff

Re: Requirements for IPv6 Firewalls

[Enno Rey]

Hi,

On Fri, Apr 18, 2014 at 11:59:04AM -0700, Doug Barton wrote:
> On 04/18/2014 12:57 AM, Enno Rey wrote:
> > I fully second Sander's input. I've been involved in IPv6 planning in a 
> > number of very large enterprises now and_none_  of them required/asked for 
> > (66/overloading) NAT for their firewall environments. A few think about 
> > very specific deployments of NPTv6 like stuff for connections to 
> > supplier/partner networks (to map those to their own address space) but 
> > these are corner cases not even relevant for their "firewalls".
> 
> How many of those networks were implementing with IPv6 PI space?

all of them



 My 
> experience has been that those customers are not interested in IPv6 NAT, 
> but instead utilize network segmentation to define "internal" vs. 
> "external."
> 
> OTOH, customers for whom PI space is not realistic (for whatever 
> reasons, and yes there are reasons) are very interested in the 
> combination of ULA + NTPv6 to handle internal resources without having 
> to worry about renumbering down the road.

true. it's just we don't see many of those (actually I've yet to encounter a 
single one) and it could be debatable if they belong to "Enterprise" networks 
(which is in the title of the ID).

best

Enno





> 
> Doug
> 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

Re: Requirements for IPv6 Firewalls

[Matt Palmer]

On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote:
> As to address the other argument in this threat on NAT / private
> addressing, PCI requirement 1.3.8 pretty much requires RFC1918 addressing
> of the computers in scope...  has anyone hinted at PCI for IPv6?

1.3.8 lists use of RFC1918 address space as one of four possible
implementations, immediately after the phrase "may include, but are not
limited to".  I don't interpret that as "pretty much requires RFC1918".

Now, if you'd like to claim that 1.3.8 is completely useless, I won't argue
with you -- it's security-by-obscurity of the worst possible form.  But
don't blame PCI compliance for any inability to deploy IPv6, because it just
ain't true.

- Matt

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 19, 2014, at 9:04 AM, Jeff Kell  wrote:

> It's how we provide access control.

Firewalls <> 'access control'.

Firewalls are one (generally, very poor and grossly misused) way of providing 
access control.  They're often wedged in where stateless ACLs in hardware-based 
routers and/or layer-3 switches would do a much better job, such as in front of 
servers:



---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[TheIpv6guy .]

On Fri, Apr 18, 2014 at 6:53 PM, Dobbins, Roland  wrote:
>
> On Apr 19, 2014, at 1:20 AM, William Herrin  wrote:
>
>> There isn't much a firewall can do to break it.
>
> As someone who sees firewalls break the Internet all the time for those whose 
> packets have the misfortune to traverse one, I must respectfully disagree.
>
> ;>
>

Yep.  I have seen many more security / availability events caused by a
firewall tipping over than anything else.  Firewalls tend to be put in
as single points of failure so that there is one point of inspection /
policy enforcement.  And, HA pairs are generally a joke.  2 failure
mode i have seen:  Firewall ALG saw a SIP packet option that it did
not like, so it reloaded itself.  In the process, it reflected the
session state with fatal information to it's HA mate, which
immediately failed.  Same story with SYN floods, too many sessions
coming in, FW cannot keep up with figuring out what is good, what is
bad... Kablamoo.  The firewall is the weakest link in the chain.


Oh, and, then there is this... where the firewall, which is the one
point of security control is in fact an open tap to your entire
network

http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140110-sbd

But, it leads to clever things like this where home routers get
hijacked as proxies...for whatever ...
http://danmcinerney.org/how-to-exploit-home-routers-for-anonymity/


I think stateful network based firewalls are more harm than good and I
would like host and applications to be the ultimate front line of
defense.  To each their own.  Just a data point.

Enjoy

CB

> ---
> Roland Dobbins  // 
>
>   Luck is the residue of opportunity and design.
>
>-- John Milton
>
>

Re: Requirements for IPv6 Firewalls

[Jeff Kell]

On 4/18/2014 9:53 PM, Dobbins, Roland wrote:
> On Apr 19, 2014, at 1:20 AM, William Herrin  wrote:
>
>> There isn't much a firewall can do to break it.
> As someone who sees firewalls break the Internet all the time for those whose 
> packets have the misfortune to traverse one, I must respectfully disagree.

If end-to-end connectivity is your idea of "the Internet", then a
firewall's primary purpose is to break the Internet.  It's how we
provide access control.

If a firewall blocks "legitimate, authorized" access then perhaps it
adds to breakage (PMTU, ICMP, other blocking) but otherwise it works.

As to address the other argument in this threat on NAT / private
addressing, PCI requirement 1.3.8 pretty  much requires RFC1918
addressing of the computers in scope...  has anyone hinted at PCI for IPv6?

Jeff

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 19, 2014, at 1:20 AM, William Herrin  wrote:

> There isn't much a firewall can do to break it.

As someone who sees firewalls break the Internet all the time for those whose 
packets have the misfortune to traverse one, I must respectfully disagree.

;>

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Glen Turner]

Fernando,

Perhaps the document should have opened with a disclaimer that it is impossible 
to describe the full customer requirements for a firewall and thus a customer 
can reasonably add additional requirements. Then everyone knows where they 
stand and we avoid stupid (perhaps contractual) arguments that a firewall is 
acceptable solely because it meets this IETF publication.

The document varies between specification and advice. My view is that it that 
as it stands the document is too specific to a particular type of firewall in a 
particular type of network to be anything other than advice, and should remove 
words such as "specify".  My view is that there is scope for a different 
document -- or a much later revision of this document -- which actually 
specifies the minimum acceptable behaviour of a IPv6 network boundary firewall.

You need an copyeditor. Expressions such as
  "but at times has also meant that a number of important/basic
  features have remained unimplemented by major firewall vendors,
  or that aforementioned features have not behaved as expected."
are simply a poor use of the language.

REQ GEN-5.
Benchmarking is far too vague. Replace with a list of tests.

REQ GEN-10
This is a requirement for the author of this specification. You should
take that requirement and implement it throughout the document, and
have a corresponding SNMP MIB which SHOULD be implemented. Counters
we can't retrieve are pointless.

REQ GEN-20
Define "basic access control list". Is that drop-and-count on destination
address prefix? That would be the understanding based on the use of that
term in Cisco IOS for IPv4.

REQ GEN-30
Which transport layers are required for stateless inspection? TCP? UDP? OSPF?

REQ GEN-50
This should not be a general requirement at all. There are good reasons not
to use TCP proxying, not the least of which is the load on the firewall.

REQ GEN-70
Doesn't allowing ACLs meet the uRPF requirement for non-routers? Is a vendor
which supports ACLs automatically compliant? If not, state so.

REQ GEN-80
Redirection of HTTPS traffic independent of other traffic is a specific
feature for content providers not justifying a MUST for all firewalls.

REQ SPC-10
This requirement squibs the most important single statement you can make
about a IPv6 firewall: defining ICMP types which SHOULD be forwarded and
those which SHOULD NOT when crossing a network boundary. This was a major
issue for IPv4 and requires greater depth for IPv6 then is given here.

REQ SPC-20
List the extension headers which SHOULD and SHOULD NOT be filtered by default
when crossing a network boundary.

REQ SPC-30:
List the routing headers which SHOULD and SHOULD NOT be filtered by default
when crossing a network boundary.

REQ SPC-40
List the options which SHOULD and SHOULD NOT be filtered by default when
crossing a network boundary.

REQ SPC-50
This requirement need much more work, as the specification is handwaving.

REQ SPC-70
Cannot be implemented in anything but a simplistic network. ICMPv6 errors
can come from anywhere on the forwarding path between the firewall and the
host. The firewall cannot tell if a ICMPv6 from an unknown address is on
the forwarding path for a connection. All it can do is validate uRPF, which
is already a requirement.

REQ SPC-80
Duplicate requirement

REQ SPC-90
Poorly expressed. Rephrase in terms of packet parsing.

REQ SPC-100
Rewriting Hop Limit? If you are going to proceed with the requirement then
*reducing* Hop Limit is the only safe behaviour, and the only which a
firewall SHOULD be required to support. If you are doing this to hide
topology then the firewall manufacturer can reduce Hop Limit to the next
lowest in a predefined set of values.

Setting Hop Limit to an arbitrary value MAY be possible, and that should
be accompanied by a note pointing out that this can lead to network failure
unless all topologies containing the firewall are loop-free at all times.


Why should a firewall support VPNs at all? Maybe you need to be clearer
about the applicability of each section to a product. Do you mean that
if a firewall implemented VPNs it must do so meeting these requirements?

REQ VPN-20 is dynamic multipoint VPNs really a MUST for all VPN servers?
You are saying that is it not possible for their to be a valid VPN design
which does not include dynamic multipoint VPN. You'll excuse my doubt on
that point.

REQ VPN-60 needs more work. Some environments require certificates and keys
to be manually altered.


DOS. There are a lot of "must be able to protect against" which is handwaving.

REQ DoS-70. This introduces a new requirement for filtering on VLAN or MPLS.
That requirement needs to be higher in the document, not hidden.

REQ DoS-80. I contest the MUST participate in blackhole infrastructure. There
seems to be an assumption in this document that all valid IP firewalls designs
are for use on Internet-connected networks. Ditto REQ DoS-85.

REQ DoS-100. Underspecified. Or is "detected" the li

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 6:10 PM, Lee Howard  wrote:
> On 4/17/14 11:51 AM, "William Herrin"  wrote:
>>Also, I note your draft is entitled "Requirements for IPv6 Enterprise
>>Firewalls." Frankly, no "enterprise" firewall will be taken seriously
>>without address-overloaded NAT. I realize that's a controversial
>>statement in the IPv6 world but until you get past it you're basically
>>wasting your time on a document which won't be useful to industry.
>
> You've said this before, and it is still an absurdly over-broad statement.

Hi Lee,

That tends to happen when one takes a nuanced topic involving the
intersection of technology with human social behavior and boils it
down to two sentences. Perhaps I could have said, "taken seriously by
enough of your target audience without."

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 7:06 PM, William Herrin  wrote:
> On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu  wrote:
>> Defense in depth, to my knowledge - and feel free to correct me, is to have
>> defenses at every point in the network and at the host level to protect
>> against different attack vectors that are possible at those point.
>
> And a heart attack is that you clutch your chest and fall over dead.
> You describe what defense in depth looks like, not what it is.
>
> Defense in depth is that you have a fence and a security guard and a
> spotlight. And a locked door, an alarm system and a safe too. But you
> don't just have the fence, the door and the safe, a single form of
> protection at each point. That would be a shallow defense.

Put more succinctly: depth isn't where you place the defenses, it's
how many defenses times the quality of each defense that an adversary
has to slip past. If an adversary has to bypass three defenses, that's
more shallow than if he has to bypass the same three and three more.
Whether all six are at the perimeter or half are at the perimeter two
are at the host and one is in the application is only indirectly
relevant to the depth of your defense.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[George Herbert]

Lee Howard:
>
> So, yeah, you have to give your firewall administrator time to walk
> through the rules and figure out what they ought to be in IPv6.  Your
> firewall administrator has been wanting to clean up the rules for the last
> two years, anyway.



The arrogance in this assertion is amazing.

You're describing best practice.  Yes, of course, you should have well
documented technical and business needs for what's open and what's closed
in firewalls, and should have traceability from the rules in place to the
requirements, and be able to walk the rules and understand them and
reinterpret them from v4 to v6, to a new firewall vendor, etc etc.

Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE.

Policymakers baldly asserting that it should be otherwise does not change
reality on the ground in numerous enterprise customers.

You and the others are ascribing to me and William blame for this.  Shoot
the messenger all you want; all we're doing it relaying on why we've failed
to convert all our customers.  It's not because we don't understand
firewalls or v6.  It's because the real world is substantially messier,
often man-decades of work messier than you all assert it could possibly be.

Again - policy community blinders on understanding what real systems are
like out in the world has repeatedly shot the conversion in the legs.  If
you're going to start floating standards for this kind of stuff, then
listen to feedback on why things are failing.




On Fri, Apr 18, 2014 at 3:36 PM, Lee Howard  wrote:

>
>
> On 4/17/14 4:45 PM, "George Herbert"  wrote:
> >
> >> There's a fair argument to be made which says that kind of NAT is
> >> > unhealthy. If its proponents are correct, they'll win that argument
> >> > later on with NAT-incompatible technology that enterprises want. After
> >> > all, enterprise security folk didn't want the Internet in the
> >> > corporate network at all, but having a web browser on every desk is
> >> > just too darn useful. Where they won't win that argument is in the
> >> > stretch of maximum risk for the enterprise security folk.
> >> >
> >> >
> >> Any technology has associated risks, it's a matter of how you
> >> reduce/mitigate them.
> >> This paranoia thingie about IPv6 is getting a bit old.
> >> Just because you don't (seem to) understand how it works, it doesn't
> >>mean
> >> no one else should use it.
> >
> >
> >
> >You are missing the point.
> >
> >Granted, anyone who is IPv6 aware doing a green-field enterprise firewall
> >design today should probably choose another way than NAT.
> >
> >What you are failing is that "redesign firewall rules and approach from
> >scratch along with the IPv6 implementation" usually is not the chosen
> >path,
> >versus "re-implement the same v4 firewall rules and technologies in IPv6
> >for the IPv6 implementation", because all the IPv6 aware net admins are
> >having too much to do dealing with all the other conversion issues, vendor
> >readiness all across the stack, etc.
>
> One of the things we (operator hat) like about IPv6 is that we get to
> clean up the mess we made in IPv4. In many cases we've significantly
> reduced the number of firewall rules or ACL lines, because we don't have
> disaggregate blocks we have to stack up.
>
> On my enterprise firewalls, I had a couple of DMZs, a couple of internal
> networks, and policies for what could get where.  Firewalls referred to
> objects of various kinds, some of which had multiple addresses listed;
> putting servers with similar policies in a single /64 (or a /60 if I
> needed separate VLANs) would have simplified things.  And the policy/rule
> difference between net 10 addresses internally and GUA prefixes internally
> is null.
>
> So, yeah, you have to give your firewall administrator time to walk
> through the rules and figure out what they ought to be in IPv6.  Your
> firewall administrator has been wanting to clean up the rules for the last
> two years, anyway.
>
> Even if the above doesn't apply to you, what rules do you have that you
> can't copy?
> * deny ICMP to any.  Can't do that.  Must allow at least some messages.
> * deny (public address range) to (private address range) unless initiated
> form inside.  Substitute external and internal prefixes.
> * deny (outside) to (DMZ) except (port ranges).  Same in IPv6.
> * deny (inside) to (DMZ) except (port ranges).  Same in IPv6.
>
> As I recall, the rules were in place even when we used NAT.  If "no
> thinking required" firewall administration is your goal, I'm not clear how
> this interferes.
>
>
> >
> >Variations on this theme are part of why it's 2014 and IPv6 hasn't already
> >taken over the world.  The more rabid IPv6 proponents have in fact shot
> >the
> >transition in the legs repeatedly, and those of us who have been on the
> >front lines would like you all to please shut up and get out of the way so
> >we can actually finish effecting v6 deployment and move on to mopping up
> >things like NAT later.
> >
> >This i

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu  wrote:
> On Fri, Apr 18, 2014 at 6:02 PM, William Herrin  wrote:
>> 4. Defense in depth is a core principle of all security, network and
>> physical. If you don't practice it, your security is weak. Equipment
>> which is not externally addressable (due to address-overloaded NAT)
>> has an additional obstruction an adversary must bypass versus an
>> identical system where the equipment is externally addressable (1:1
>> NAT, static port translation and simple routing). This constrains the
>> kinds of attacks an adversary may employ.
>
> Let's make it simple:
>
> Scenario (A) w/ IPv4
> [Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address
> :80/TCP
>
> Scenario (B) w/ IPv6
> [Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP
>
>
> In scenario (A) I hide a server behind a firewall and to a simple
> destination NAT (most common setup found in all companies).
> In scenario (B) I have a firewall rule that only allows port 80 to a machine
> in my network.
>
>
> Explain to me how from a security standpoint Scenario (A) is better than
> scenario (B).

So your question is: how does one variant of being externally
addressable (simple routing with a packet filter or perhaps a stateful
firewall) differ from another variant of being externally addressable
(static inbound port translation)? Hell man, I don't like seeing these
in IPv4 let alone IPv6. But when I'm asking a guy to make a much
bigger leap of faith, like implementing IPv6, I don't plan to distract
him with the fact that he's taken NAT=good from the situation where
it's probably true and applied it to a situation where its value is
more dubious.


> Defense in depth, to my knowledge - and feel free to correct me, is to have
> defenses at every point in the network and at the host level to protect
> against different attack vectors that are possible at those point.

And a heart attack is that you clutch your chest and fall over dead.
You describe what defense in depth looks like, not what it is.

Defense in depth is that you have a fence and a security guard and a
spotlight. And a locked door, an alarm system and a safe too. But you
don't just have the fence, the door and the safe, a single form of
protection at each point. That would be a shallow defense.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[Matthew Kaufman]

Ignoring security, A is superior because I can change it to DNAT to the new 
server, or DNAT to the load balancer now that said server needs 10 replicas, 
etc. 

B requires re-numbering the server or *if* I am lucky enough that it is reached 
by DNS name and I can change that DNS promptly, assigning a new address and 
adding another firewall rule that didn't exist.

Matthew Kaufman

(Sent from my iPhone)

> On Apr 18, 2014, at 3:19 PM, Eugeniu Patrascu  wrote:
> 
>> On Fri, Apr 18, 2014 at 6:02 PM, William Herrin  wrote:
>> 
>> On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu 
>> wrote:
>>> On Thu, Apr 17, 2014 at 11:45 PM, George Herbert <
>> george.herb...@gmail.com>
>>> wrote:
 You are missing the point.
 
 Granted, anyone who is IPv6 aware doing a green-field enterprise
>> firewall
 design today should probably choose another way than NAT.
>>> 
>>> That's why you have gazzilions of IP addresses in IPv6, so you don't
>> need to
>>> NAT anything (among other things). I don't understand why people cling to
>>> NAT stuff when you can just route.
>> 
>> 4. Defense in depth is a core principle of all security, network and
>> physical. If you don't practice it, your security is weak. Equipment
>> which is not externally addressable (due to address-overloaded NAT)
>> has an additional obstruction an adversary must bypass versus an
>> identical system where the equipment is externally addressable (1:1
>> NAT, static port translation and simple routing). This constrains the
>> kinds of attacks an adversary may employ.
> Let's make it simple:
> 
> Scenario (A) w/ IPv4
> [Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address
> :80/TCP
> 
> Scenario (B) w/ IPv6
> [Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP
> 
> 
> In scenario (A) I hide a server behind a firewall and to a simple
> destination NAT (most common setup found in all companies).
> In scenario (B) I have a firewall rule that only allows port 80 to a
> machine in my network.
> 
> 
> Explain to me how from a security standpoint Scenario (A) is better than
> scenario (B).
> 
> 
> Defense in depth, to my knowledge - and feel free to correct me, is to have
> defenses at every point in the network and at the host level to protect
> against different attack vectors that are possible at those points. For
> example a firewall that understands traffic at the protocol level, a
> hardened application server, a hardened application, secure coding
> practices and so on depending of the complexity of the network and the
> security requirements.
> 
> 
>> Feel free to refute all four points. No doubt you have arguments you
>> personally find compelling. Your arguments will fall on deaf ears. At
>> best the arguments propose theory that runs contrary to decades of
>> many folks' experience. More likely the arguments are simply wrong.
> Just because some people have decades of experience, it doesn't mean they
> are right or know what they are doing.
> 
> 
> Eugeniu

Re: Requirements for IPv6 Firewalls

[Matt Palmer]

On Fri, Apr 18, 2014 at 06:37:28PM -0400, Lee Howard wrote:
> On 4/18/14 4:33 PM, "George Herbert"  wrote:
> >
> >If William and I fight that fight, lose it, and come back and tell you
> >"They won't go because insufficient NAT" you need to listen.  I've fought
> >this in a dozen places and lost 8 of them, not because I don't know v6,
> >but
> >because the clients have inertia and politics around security posture
> >changes (and in some cases, PCI compliance regs).
> 
> IPv6 evangelists are used to fighting inertia.
> PCI, however. . . anyone have any contacts there?

If you get to talk to them, they'll probably look at you funny and say,
"whatchoo talkin' 'bout?".  PCI DSS *does not require NAT*.  Anyone who
says differently is selling something (probably a NAT box).  You can refer
to the source documents yourself -- they're freely available
(https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf, for
example).  As a testimonial, we run a no-NAT environment and got full PCI
compliance with nary a twitch of the eyebrow.  Didn't even have to argue the
toss with anyone.

- Matt

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 6:36 PM, Lee Howard  wrote:
> Some operators want NAT.  Some don't.  There are loud voices on both
> sides. Consensus seems slightly against.

Hi Lee,

Some operators want NAT. That's it. End of discussion. This isn't a
consensus question. Some operators want NAT. Period. Full stop.
They'll hold off deploying and when IPv6 is sufficiently valuable,
they'll pay someone to give them NAT. Regardless of whether the
consensus of the IETF approves.

These are the folks who made Gauntlet and its transparent proxies the
#1 firewall product back during the bubble. They don't see the
Internet the way you do.

And if there are more of them than you think, IPv6 won't achieve
sufficient value, won't reach critical mass. Then you'll really REALLY
be stuck with NAT.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

OT: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]

[Scott Weeks]

:: There being no cable between the Hawaiian Islands 
:: and the mainland at the time

Wait...what?

https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific

"The first trans-pacific cables were completed in 1902-03, linking the 
US mainland to Hawaii in 1902 and Guam to the Philippines in 1903.
Canada, Australia, New Zealand and Fiji were also linked in 1902.

scott





--- mi...@mikea.ath.cx wrote:
From: Mike A 

On Mon, Apr 14, 2014 at 10:09:14PM +, Matthew Black wrote:
> IIRC, the message was sent via courier instead of cable or telephone to
> prevent interception. Did the military not even trust its own cryptographic
> methods? Or did they not think withdrawal of the Japanese ambassador was not
> very critical?

The message was sent by Western Union. There being no cable between the
Hawaiian Islands and the mainland at the time, the message went by commercial
radio, in plaintext, and thence by civilian bicycle messenger (of Japanese
ancestry, as it happened) to Fort Shafter, where it was read while the attack
was in progress.

David Kahn's fine book, _The Codebreakers_, discusses this in rather more
detail. I recommend the original version; the paperback and later hardback
editions contain rather less meat.

-- 
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin 

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/18/14 4:33 PM, "George Herbert"  wrote:
>
>If William and I fight that fight, lose it, and come back and tell you
>"They won't go because insufficient NAT" you need to listen.  I've fought
>this in a dozen places and lost 8 of them, not because I don't know v6,
>but
>because the clients have inertia and politics around security posture
>changes (and in some cases, PCI compliance regs).


IPv6 evangelists are used to fighting inertia.
PCI, however. . . anyone have any contacts there?

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/17/14 4:45 PM, "George Herbert"  wrote:
>
>> There's a fair argument to be made which says that kind of NAT is
>> > unhealthy. If its proponents are correct, they'll win that argument
>> > later on with NAT-incompatible technology that enterprises want. After
>> > all, enterprise security folk didn't want the Internet in the
>> > corporate network at all, but having a web browser on every desk is
>> > just too darn useful. Where they won't win that argument is in the
>> > stretch of maximum risk for the enterprise security folk.
>> >
>> >
>> Any technology has associated risks, it's a matter of how you
>> reduce/mitigate them.
>> This paranoia thingie about IPv6 is getting a bit old.
>> Just because you don't (seem to) understand how it works, it doesn't
>>mean
>> no one else should use it.
>
>
>
>You are missing the point.
>
>Granted, anyone who is IPv6 aware doing a green-field enterprise firewall
>design today should probably choose another way than NAT.
>
>What you are failing is that "redesign firewall rules and approach from
>scratch along with the IPv6 implementation" usually is not the chosen
>path,
>versus "re-implement the same v4 firewall rules and technologies in IPv6
>for the IPv6 implementation", because all the IPv6 aware net admins are
>having too much to do dealing with all the other conversion issues, vendor
>readiness all across the stack, etc.

One of the things we (operator hat) like about IPv6 is that we get to
clean up the mess we made in IPv4. In many cases we've significantly
reduced the number of firewall rules or ACL lines, because we don't have
disaggregate blocks we have to stack up.

On my enterprise firewalls, I had a couple of DMZs, a couple of internal
networks, and policies for what could get where.  Firewalls referred to
objects of various kinds, some of which had multiple addresses listed;
putting servers with similar policies in a single /64 (or a /60 if I
needed separate VLANs) would have simplified things.  And the policy/rule
difference between net 10 addresses internally and GUA prefixes internally
is null.

So, yeah, you have to give your firewall administrator time to walk
through the rules and figure out what they ought to be in IPv6.  Your
firewall administrator has been wanting to clean up the rules for the last
two years, anyway. 

Even if the above doesn't apply to you, what rules do you have that you
can't copy?
* deny ICMP to any.  Can't do that.  Must allow at least some messages.
* deny (public address range) to (private address range) unless initiated
form inside.  Substitute external and internal prefixes.
* deny (outside) to (DMZ) except (port ranges).  Same in IPv6.
* deny (inside) to (DMZ) except (port ranges).  Same in IPv6.

As I recall, the rules were in place even when we used NAT.  If "no
thinking required" firewall administration is your goal, I'm not clear how
this interferes.


>
>Variations on this theme are part of why it's 2014 and IPv6 hasn't already
>taken over the world.  The more rabid IPv6 proponents have in fact shot
>the
>transition in the legs repeatedly, and those of us who have been on the
>front lines would like you all to please shut up and get out of the way so
>we can actually finish effecting v6 deployment and move on to mopping up
>things like NAT later.
>
>This is why listening to operators is important.

Some operators want NAT.  Some don't.  There are loud voices on both
sides. Consensus seems slightly against.
However, ULA + NPT works.

Lee

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Fri, Apr 18, 2014 at 10:49 PM, Jim Clausing  wrote:

> And maybe I'm just dense, but ho one has been able to tell me how I
> accomplish this in IPv6 without NAT, I have the requirement in certain
> circumstances to transparently redirect all outbound DNS (well, on TCP or
> UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers.  No,
> simply blocking it at the firewall and making the user "fix" the problem is
> not an option (especially when the problem is created by malware).  It is a
> simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? Not
> flaming or anything, but I really want to know how I'm supposed to
> accomplish that in the ideal IPv6 world with no NAT?
>
>
Nothing stops you from using NAT :)

This discussion got a bit off track. I'm not saying NAT should be banned
completely, I'm saying that with IPv6 we can actually simplify things a lot
get rid of all hacks we had to do in the network do get services up and
running (e.g. using a firewall's public ip address to hide several distinct
services behind it on different hosts, like web, dns, smtp etc).

I believe in simplicity, and now IPv6 for me makes things simple: I can
have all the IP addresses I want and do not need to use hacks to get things
working because no one would give 2048 IPv4 addresses just to do stuff with
them and run lots of servers with "public" IP addresses.

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Fri, Apr 18, 2014 at 6:02 PM, William Herrin  wrote:

> On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu 
> wrote:
> > On Thu, Apr 17, 2014 at 11:45 PM, George Herbert <
> george.herb...@gmail.com>
> > wrote:
> >> You are missing the point.
> >>
> >> Granted, anyone who is IPv6 aware doing a green-field enterprise
> firewall
> >> design today should probably choose another way than NAT.
> >>
> >
> > That's why you have gazzilions of IP addresses in IPv6, so you don't
> need to
> > NAT anything (among other things). I don't understand why people cling to
> > NAT stuff when you can just route.
>
> 4. Defense in depth is a core principle of all security, network and
> physical. If you don't practice it, your security is weak. Equipment
> which is not externally addressable (due to address-overloaded NAT)
> has an additional obstruction an adversary must bypass versus an
> identical system where the equipment is externally addressable (1:1
> NAT, static port translation and simple routing). This constrains the
> kinds of attacks an adversary may employ.
>
>
Let's make it simple:

Scenario (A) w/ IPv4
[Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address
:80/TCP

Scenario (B) w/ IPv6
[Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP


In scenario (A) I hide a server behind a firewall and to a simple
destination NAT (most common setup found in all companies).
In scenario (B) I have a firewall rule that only allows port 80 to a
machine in my network.


Explain to me how from a security standpoint Scenario (A) is better than
scenario (B).


Defense in depth, to my knowledge - and feel free to correct me, is to have
defenses at every point in the network and at the host level to protect
against different attack vectors that are possible at those points. For
example a firewall that understands traffic at the protocol level, a
hardened application server, a hardened application, secure coding
practices and so on depending of the complexity of the network and the
security requirements.


> Feel free to refute all four points. No doubt you have arguments you
> personally find compelling. Your arguments will fall on deaf ears. At
> best the arguments propose theory that runs contrary to decades of
> many folks' experience. More likely the arguments are simply wrong.
>
>
Just because some people have decades of experience, it doesn't mean they
are right or know what they are doing.


Eugeniu

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/17/14 11:51 AM, "William Herrin"  wrote:

>
>Also, I note your draft is entitled "Requirements for IPv6 Enterprise
>Firewalls." Frankly, no "enterprise" firewall will be taken seriously
>without address-overloaded NAT. I realize that's a controversial
>statement in the IPv6 world but until you get past it you're basically
>wasting your time on a document which won't be useful to industry.

You've said this before, and it is still an absurdly over-broad statement.
Many security professionals have deployed enterprise firewalls to their
satisfaction without NAT-PT.

We had this debate, what, a month ago?  Your position hasn't changed.  No
new use cases have emerged.  Are we done here?

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/17/14 8:51 PM, "Matthew Kaufman"  wrote:

>While you're at it, the document can explain to admins who have been
>burned, often more than once, by the pain of re-numbering internal
>services at static addresses how IPv6 without NAT will magically solve
>this problem.


http://datatracker.ietf.org/doc/rfc6879/

This document analyzes events that cause renumbering and describes
   the current renumbering methods.  These are described in three
   categories: those applicable during network design, those applicable
   during preparation for renumbering, and those applicable during the
   renumbering operation.


Lee

>
>Matthew Kaufman
>
>(Sent from my iPhone)
>
>> On Apr 17, 2014, at 4:20 PM, Brandon Ross  wrote:
>> 
>> On Thu, 17 Apr 2014, Sander Steffann wrote:
>> 
 Also, I note your draft is entitled "Requirements for IPv6 Enterprise
 Firewalls." Frankly, no "enterprise" firewall will be taken seriously
 without address-overloaded NAT. I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.
>>> 
>>> I disagree. While there certainly will be organisations that want such
>>>a 'feature' it is certainly not a requirement for every (I hope most,
>>>but I might be optimistic) enterprises.
>> 
>> And I not only agree with Sander, but would also argue for a definitive
>>statement in a document like this SPECIFICALLY to help educate the
>>enterprise networking community on how to implement a secure border for
>>IPv6 without the need for NAT.  Having a document to point at that has
>>been blessed by the IETF/community is key to helping recover the
>>end-to-end principle.  Such a document may or may not be totally in
>>scope for a "firewall" document, but should talk about concepts like
>>default-deny inbound traffic, stateful inspection and the use of address
>>space that is not announced to the Internet and/or is completely blocked
>>at borders for all traffic.
>> 
>> Heck, we could even make it less specific to IPv6 and create a document
>>that describes these concepts and show how NAT is not necessary nor wise
>>for IPv4, either.  (Yes, yes, other than address conservation.)
>> 
>> -- 
>> Brandon Ross  Yahoo & AIM:
>>BrandonNRoss
>> +1-404-635-6667ICQ:
>>2269442
>> Skype:
>>brandonross
>> Schedule a meeting:  http://www.doodle.com/bross
>> 
>
>

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 10-Apr-14 -to- 17-Apr-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS7029   152556  5.1% 289.5 -- WINDSTREAM - Windstream 
Communications Inc,US
 2 - AS982972653  2.4%  78.0 -- BSNL-NIB National Internet 
Backbone,IN
 3 - AS28573   40432  1.4%  16.5 -- NET Serviços de Comunicação 
S.A.,BR
 4 - AS29571   35579  1.2% 173.6 -- CITelecom-AS,CI
 5 - AS33597   33070  1.1% 194.5 -- INFORELAY - InfoRelay Online 
Systems, Inc.,US
 6 - AS45169   30868  1.0%2057.9 -- GLOBAL-DESCON-AS-AP Descon 
Limited,IN
 7 - AS840228794  1.0%  16.7 -- CORBINA-AS OJSC "Vimpelcom",RU
 8 - AS13188   27400  0.9%  26.4 -- BANKINFORM-AS TOV 
"Bank-Inform",UA
 9 - AS31148   25814  0.9%  25.4 -- FREENET-AS Freenet Ltd.,UA
10 - AS48159   21835  0.7%  83.0 -- TIC-AS Telecommunication 
Infrastructure Company,IR
11 - AS13118   21752  0.7% 472.9 -- ASN-YARTELECOM OJSC 
Rostelecom,RU
12 - AS36998   21728  0.7%  13.3 -- SDN-MOBITEL,SD
13 - AS10620   21505  0.7%   9.5 -- Telmex Colombia S.A.,CO
14 - AS41691   21050  0.7% 877.1 -- SUMTEL-AS-RIPE Summa Telecom 
LLC,RU
15 - AS28146   19506  0.7% 354.7 -- Mhnet Empreendimentos Ltda,BR
16 - AS390 18473  0.6%  84.0 -- AFCONC-BLOCK1-AS - 754th 
Electronic Systems Group,US
17 - AS755218185  0.6%  16.5 -- VIETEL-AS-AP Viettel 
Corporation,VN
18 - AS14259   17893  0.6%  67.3 -- Gtd Internet S.A.,CL
19 - AS475517510  0.6%  12.3 -- TATACOMM-AS TATA Communications 
formerly VSNL is Leading ISP,IN
20 - AS477516241  0.5% 193.3 -- GLOBE-TELECOM-AS Globe 
Telecoms,PH


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS181358869  0.3%8869.0 -- BTV BTV Cable television,JP
 2 - AS346356517  0.2%6517.0 -- LIBERTY-AS Liberty Poland 
S.A.,PL
 3 - AS628922589  0.1%2589.0 -- TW-EIS - Turner Broadcasting 
System, Inc.,US
 4 - AS544657242  0.2%2414.0 -- QPM-AS-1 - QuickPlay Media 
Inc.,US
 5 - AS204502148  0.1%2148.0 -- THL16-ASN - Trojan Hosting, 
LLC.,US
 6 - AS45169   30868  1.0%2057.9 -- GLOBAL-DESCON-AS-AP Descon 
Limited,IN
 7 - AS389096018  0.2%2006.0 -- MURAMATSU-AS-AP Muramatsu Group 
Inc. Transit AS,PH
 8 - AS588225835  0.2%1945.0 -- IDNIC-UNESA-AS-ID Universitas 
Negeri Surabaya,ID
 9 - AS23732  0.1%2024.0 -- UDEL-DCN - University of 
Delaware,US
10 - AS66293  0.4%1852.2 -- NOAA-AS - NOAA,US
11 - AS225573251  0.1%1625.5 -- UTHL - UNITED TLD HOLDCO LTD,KY
12 - AS31404  0.1%1987.0 -- MIT-GATEWAYS - Massachusetts 
Institute of Technology,US
13 - AS336431393  0.1%1393.0 -- JELLYBELLY - Jelly Belly Candy 
Company,US
14 - AS603451259  0.0%1259.0 -- NBITI-AS Nahjol Balagheh 
International Research Institution,IR
15 - AS2167 5665  0.2%1133.0 -- HPES - Hewlett-Packard 
Company,US
16 - AS41691   21050  0.7% 877.1 -- SUMTEL-AS-RIPE Summa Telecom 
LLC,RU
17 - AS232951475  0.1% 737.5 -- EA-01 - Extend America,US
18 - AS54274 718  0.0% 718.0 -- HENNYPENNYCORP - Henny Penny 
Corporation,US
19 - AS57201 703  0.0% 703.0 -- EDF-AS Estonian Defence 
Forces,EE
20 - AS22688 653  0.0% 653.0 -- DOLGENCORP - Dollar General 
Corporation,US


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 109.161.64.0/20   21627  0.7%   AS13118 -- ASN-YARTELECOM OJSC 
Rostelecom,RU
 2 - 89.221.206.0/24   20887  0.7%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom 
LLC,RU
 3 - 121.52.144.0/24   13243  0.4%   AS17557 -- PKTELECOM-AS-PK Pakistan 
Telecommunication Company Limited,PK
 AS45773 -- HECPERN-AS-PK PERN AS Content 
Servie Provider, Islamabad, Pakistan,PK
 4 - 192.58.232.0/24   11100  0.3%   AS6629  -- NOAA-AS - NOAA,US
 5 - 166.149.142.0/24  10047  0.3%   AS7029  -- WINDSTREAM - Windstream 
Communications Inc,US
 6 - 42.83.48.0/20  8869  0.3%   AS18135 -- BTV BTV Cable television,JP
 7 - 120.28.62.0/24 8038  0.2%   AS4775  -- GLOBE-TELECOM-AS Globe 
Telecoms,PH
 8 - 205.247.12.0/247778  0.2%   AS6459  -- TRANSBEAM - I-2000, Inc.,US
 9 - 222.127.0.0/24 7516  0.2%   AS4775  -- GLOBE-TELECOM-AS Globe 
Telecoms,PH
10 - 50.96.132.0/24 7466  0.2%   AS7029  -- WINDSTREAM - Windstream 
Communications Inc,US
11 - 206.152.15.0/247238  0.2%   AS54465 -- QPM-AS-1 - QuickPlay Media 
Inc.,US
12 - 194.126.221.0/24   6517  0.2%   AS34635 -- LIBERTY-AS Liberty Poland 
S.A.,PL
13 - 210.4.14.0/24  601

The Cidr Report

[cidr-report]

This report has been generated at Fri Apr 18 21:13:52 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/2.0 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
11-04-14498748  282207
12-04-14498501  281955
13-04-14498250  282063
14-04-14498353  282141
15-04-14498798  282300
16-04-14499258  282348
17-04-14499301  282302
18-04-14499254  282237


AS Summary
 46860  Number of ASes in routing system
 19112  Number of ASes announcing only one prefix
  3741  Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.,BR
  119829504  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 18Apr14 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 499535   282214   21732143.5%   All ASes

AS28573 3741  271 347092.8%   NET Serviços de Comunicação
   S.A.,BR
AS6389  2992   56 293698.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.,US
AS17974 2780  238 254291.4%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia,ID
AS4766  2951  923 202868.7%   KIXS-AS-KR Korea Telecom,KR
AS18881 1924   37 188798.1%   Global Village Telecom,BR
AS1785  2194  483 171178.0%   AS-PAETEC-NET - PaeTec
   Communications, Inc.,US
AS10620 2835 1340 149552.7%   Telmex Colombia S.A.,CO
AS18566 2047  565 148272.4%   MEGAPATH5-US - MegaPath
   Corporation,US
AS36998 1634  156 147890.5%   SDN-MOBITEL,SD
AS4323  2929 1510 141948.4%   TWTC - tw telecom holdings,
   inc.,US
AS7303  1758  457 130174.0%   Telecom Argentina S.A.,AR
AS4755  1844  608 123667.0%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP,IN
AS7545  2232 1075 115751.8%   TPG-INTERNET-AP TPG Telecom
   Limited,AU
AS7552  1219  110 110991.0%   VIETEL-AS-AP Viettel
   Corporation,VN
AS22561 1309  241 106881.6%   AS22561 - CenturyTel Internet
   Holdings, Inc.,US
AS6983  1228  217 101182.3%   ITCDELTA - Earthlink, Inc.,US
AS9829  1622  733  88954.8%   BSNL-NIB National Internet
   Backbone,IN
AS22773 2416 1593  82334.1%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.,US
AS24560 1123  302  82173.1%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services,IN
AS4808  1205  387  81867.9%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network,CN
AS4788  1028  253  77575.4%   TMNET-AS-AP TM Net, Internet
   Service Provider,MY
AS18101  946  188  75880.1%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI,IN
AS7738   914  184  73079.9%   Telemar Norte Leste S.A.,BR
AS8151  1408  678  73051.8%   Uninet S.A. de C.V.,MX
AS701   1480  751  72949.3%   UUNET - MCI Communications
   Services, Inc. d/b/a Verizon
   Business,US
AS26615  819  109  71086.7%   Tim Celular S.A.,BR
AS855755   57  69892.5%   CANET-ASN-4 - Bell Aliant
   Regional Communications,
   Inc.,CA
AS6147   779  112  66785.6%   Telefonica del Peru S.A.A.,PE
AS9808   994  327  

Re: Requirements for IPv6 Firewalls

[George Herbert]

On Fri, Apr 18, 2014 at 10:15 AM, Timothy Morizot wrote:

> On Apr 18, 2014 10:04 AM, "William Herrin"  wrote:
> > That's correct: you don't understand. Until you do, just accept: there
> > are more than a few folks who want to, intend to and will use NAT for
> > IPv6. They will wait until NAT is available in their preferred
> > products before making any significant deployment efforts.
>
> Actually, the few like you will hold off until they are behind the curve,
> then scramble to catch up. Good luck with that strategy!
>


Again.  You're speaking down to William as if he's not IPv6 aware, which is
wrong, and ascribing to him misunderstandings and resistance that he (and
I) are trying to communicate to explain why customers in real life are
lagging so badly.

The reason the IPv6 market penetration is so poor right now is because of
antagonistic attitudes like this when actual implementers in the field try
to feed back what the actual, real objections are that are slowing things
down.  "That shouldn't happen," is not acceptable as a response to an
actual user saying "No, not until I get NAT.".

If William and I fight that fight, lose it, and come back and tell you
"They won't go because insufficient NAT" you need to listen.  I've fought
this in a dozen places and lost 8 of them, not because I don't know v6, but
because the clients have inertia and politics around security posture
changes (and in some cases, PCI compliance regs).


-- 
-george william herbert
george.herb...@gmail.com

Re: Cogent to Comcast IPv6 broken?

[TheIpv6guy .]

On Fri, Apr 18, 2014 at 11:12 AM, Will Orton  wrote:
> Cogent from various west coast USA locations seems to have trouble getting to 
> some Comcast ipv6 addresses:
>
> Cogent LG Los Angeles to www.comcast6.net
> traceroute to 2001:558:fe16:7:69:252:216:215 
> (2001:558:fe16:7:69:252:216:215), 30 hops max, 80 byte packets
>  1  2001:550:1:317::1 (2001:550:1:317::1)  70.184 ms  70.181 ms
>  2  * *
>  3  * *
>  4  2001:550:4::51 (2001:550:4::51)  15.013 ms  14.981 ms
>  5  * *
>  6  * *
> [ ... ]
>
>
> Cogent LG San Francisco ipv6 trace to www.comcast6.net
>  traceroute to 2001:558:fe16:7:69:252:216:215 
> (2001:558:fe16:7:69:252:216:215), 30 hops max, 80 byte packets
>  1  2001:550:1:31f::1 (2001:550:1:31f::1)  0.367 ms  0.369 ms
>  2  * *
>  3  * *
>  4  * *
> [ ... ]
>
> Cogent LG San Jose ipv6 ping to www.comcast6.net
> PING 2001:558:fe16:7:69:252:216:215(2001:558:fe16:7:69:252:216:215) 56 data 
> bytes
>
> --- 2001:558:fe16:7:69:252:216:215 ping statistics ---
> 5 packets transmitted, 0 received, 100% packet loss, time 13999ms
>
>
> Cogent LG San Jose ipv6 ping to speedtest.comcast.net (Los Angeles does same 
> thing, but Kansas City works):
> PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes
>
> --- 2001:558:fe2a:3:69:241:64:6 ping statistics ---
> 5 packets transmitted, 0 received, 100% packet loss, time 14000ms
>
> from Los Angeles same thing, but from Cogent's LG Kansas City it works:
> PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes
> 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=1 ttl=55 time=35.6 ms
> 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=2 ttl=55 time=35.7 ms
> 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=3 ttl=55 time=35.6 ms
> 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=4 ttl=55 time=35.6 ms
> 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=5 ttl=55 time=35.6 ms
>
> --- 2001:558:fe2a:3:69:241:64:6 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4043ms
> rtt min/avg/max/mdev = 35.620/35.676/35.734/0.241 ms
>
>
> This is similar to issues I see with a Cogent IPv6/BGP-enabled transit 
> connection in Los Angeles to a random
> Comcast customer address (that is otherwise up and reachable from HE.net, 
> NTT, etc):
>
> (from router with ipv6 BGP Cogent transit connection):
> traceroute6 to 2601:7:1300:3d2::1 (2601:7:1300:3d2::1) from 
> 2001:550:2:18::5:2, 64 hops max, 12 byte packets
>  1  2001:550:2:18::5:1 (2001:550:2:18::5:1)  1.903 ms  1.120 ms  10.771 ms
>  2  * * *
>  3  * 2001:550::57 (2001:550::57)  15.654 ms *
>  MPLS Label=19852 CoS=2 TTL=255 S=0
>  MPLS Label=19207 CoS=2 TTL=255 S=1
>  4  * * *
>
>
> I have Cogent ticket #HD005706297  on that but I'm being ignored.
> I see the similar things from Cogent IP6 transit out of San Jose.
>
> Anyone at Cogent able to look at this? I basically blackhole big chunks of 
> Comcast ipv6 on my network when I
> enable ipv6 to Cogent.
>
>
> -Will
>

This is probably a better discussion for outages@ ... but ... i notice
that i could NOT get to anything from IPv6 on Comcast at home this
morning.

And quick look at their comcast route servers shows things are NOT ok

route-server.newyork.ny.ibone>ping www.yahoo.com
Translating "www.yahoo.com"...domain server (68.87.64.164) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4998:F00B:1FE::3001, timeout is
2 seconds:
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
route-server.newyork.ny.ibone>ping www.facebook.com
Translating "www.facebook.com"...domain server (68.87.64.164) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A03:2880:2130:7F07:FACE:B00C:0:1,
timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
route-server.newyork.ny.ibone>ping www.google.com
Translating "www.google.com"...domain server (68.87.64.164) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2607:F8B0:400C:C04::6A, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)

Re: Requirements for IPv6 Firewalls

[Jim Clausing]

And maybe I'm just dense, but ho one has been able to tell me how I 
accomplish this in IPv6 without NAT, I have the requirement in certain 
circumstances to transparently redirect all outbound DNS (well, on TCP or 
UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers.  No, 
simply blocking it at the firewall and making the user "fix" the problem 
is not an option (especially when the problem is created by malware).  It 
is a simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? 
Not flaming or anything, but I really want to know how I'm supposed to 
accomplish that in the ideal IPv6 world with no NAT?


--
Jim Clausing
GIAC GSE #26, GREM(G), CISSP
GPG fingerprint = A507 774A 39D6 A702 9F7C  8808 3D13 77B8 AACD 848D

On or about Fri, 18 Apr 2014, Simon Perreault pontificated thusly:


Le 2014-04-18 14:57, William Herrin a écrit :

Excluding references and remarks RFC 6888 is 8 pages long with 15
total requirements. Short.


Given the trend toward ever-fluffier RFCs, I'll take that as a
compliment. :)


I'll let the firewall document's authors speak for themselves about
their document's purpose. In the abstract, they said: ''This has
typically been a problem for network operators, who typically have to
produce a "Request for Proposal" from scratch that describes such
features.''

That says, "discriminator for potential purchases" to me. What's your take?


I agree with your interpretation, and I disagree with the intent.


I agree that a "don't break the Internet' firewall requirements
document could have utility. But that doesn't appear to be this
document. And if done well, such a document would be short just like
RFC 6888.


Full agreement.

Simon

Re: Requirements for IPv6 Firewalls

[Simon Perreault]

Le 2014-04-18 14:57, William Herrin a écrit :
> Excluding references and remarks RFC 6888 is 8 pages long with 15
> total requirements. Short.

Given the trend toward ever-fluffier RFCs, I'll take that as a
compliment. :)

> I'll let the firewall document's authors speak for themselves about
> their document's purpose. In the abstract, they said: ''This has
> typically been a problem for network operators, who typically have to
> produce a "Request for Proposal" from scratch that describes such
> features.''
> 
> That says, "discriminator for potential purchases" to me. What's your take?

I agree with your interpretation, and I disagree with the intent.

> I agree that a "don't break the Internet' firewall requirements
> document could have utility. But that doesn't appear to be this
> document. And if done well, such a document would be short just like
> RFC 6888.

Full agreement.

Simon

Re: Requirements for IPv6 Firewalls

[Doug Barton]

On 04/18/2014 12:57 AM, Enno Rey wrote:

I fully second Sander's input. I've been involved in IPv6 planning in a number of very 
large enterprises now and_none_  of them required/asked for (66/overloading) NAT for 
their firewall environments. A few think about very specific deployments of NPTv6 like 
stuff for connections to supplier/partner networks (to map those to their own address 
space) but these are corner cases not even relevant for their "firewalls".


How many of those networks were implementing with IPv6 PI space? My 
experience has been that those customers are not interested in IPv6 NAT, 
but instead utilize network segmentation to define "internal" vs. 
"external."


OTOH, customers for whom PI space is not realistic (for whatever 
reasons, and yes there are reasons) are very interested in the 
combination of ULA + NTPv6 to handle internal resources without having 
to worry about renumbering down the road.


Doug

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 2:32 PM, Simon Perreault  wrote:
> Le 2014-04-18 14:20, William Herrin a écrit :
>> That would either be a very short document or a document so
>> ideologically loaded that it has no technical utility. The Internet is
>> pretty resilient. There isn't much a firewall can do to break it.
>
> In IETF we routinely use the phrase "breaking the Internet" to mean
> something rather more limited than "breaking all of the Internet". There
> are tons of things firewalls can do, and some do today, that would be
> considered breaking the Internet.
>
> FYI, we had a similar document targeted at CGNs:
>
> http://tools.ietf.org/html/rfc6888

Excluding references and remarks RFC 6888 is 8 pages long with 15
total requirements. Short.

I'll let the firewall document's authors speak for themselves about
their document's purpose. In the abstract, they said: ''This has
typically been a problem for network operators, who typically have to
produce a "Request for Proposal" from scratch that describes such
features.''

That says, "discriminator for potential purchases" to me. What's your take?

I agree that a "don't break the Internet' firewall requirements
document could have utility. But that doesn't appear to be this
document. And if done well, such a document would be short just like
RFC 6888.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[Simon Perreault]

Le 2014-04-18 14:20, William Herrin a écrit :
> On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault  wrote:
>> IMHO, what the IETF can do is recommend a set of behavioural traits that
>> make IPv6 firewalls behave like good citizens in the Internet ecosystem.
>> Meaning that a firewall that obeys those requirements will not break the
>> Internet. For example, passing ICMPv6 Too Big messages is important to
>> not break the Internet.
> 
> That would either be a very short document or a document so
> ideologically loaded that it has no technical utility. The Internet is
> pretty resilient. There isn't much a firewall can do to break it.

In IETF we routinely use the phrase "breaking the Internet" to mean
something rather more limited than "breaking all of the Internet". There
are tons of things firewalls can do, and some do today, that would be
considered breaking the Internet.

FYI, we had a similar document targeted at CGNs:

http://tools.ietf.org/html/rfc6888

>From the abstract:

   This document describes behavior that is required of those multi-
   subscriber NATs for interoperability.  It is not an IETF endorsement
   of CGNs or a real specification for CGNs; rather, it is just a
   minimal set of requirements that will increase the likelihood of
   applications working across CGNs.

That is exactly the kind of requirements I am thinking of when I say
"not breaking the Internet". Still, there were a few "feature shopping
list" requirements that crept into that RFC. It's far from perfect.

Simon

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault  wrote:
> IMHO, what the IETF can do is recommend a set of behavioural traits that
> make IPv6 firewalls behave like good citizens in the Internet ecosystem.
> Meaning that a firewall that obeys those requirements will not break the
> Internet. For example, passing ICMPv6 Too Big messages is important to
> not break the Internet.

That would either be a very short document or a document so
ideologically loaded that it has no technical utility. The Internet is
pretty resilient. There isn't much a firewall can do to break it.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 19 Apr, 2014

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  49
Prefixes after maximum aggregation:  193201
Deaggregation factor:  2.55
Unique aggregates announced to Internet: 242977
Total ASes present in the Internet Routing Table: 46643
Prefixes per ASN: 10.55
Origin-only ASes present in the Internet Routing Table:   35761
Origin ASes announcing only one prefix:   16379
Transit ASes present in the Internet Routing Table:6050
Transit-only ASes present in the Internet Routing Table:174
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  53
Max AS path prepend of ASN ( 50404)  51
Prefixes from unregistered ASNs in the Routing Table:  1858
Unregistered ASNs in the Routing Table: 473
Number of 32-bit ASNs allocated by the RIRs:   6417
Number of 32-bit ASNs visible in the Routing Table:4832
Prefixes from 32-bit ASNs in the Routing Table:   15924
Number of bogon 32-bit ASNs visible in the Routing Table:90
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:440
Number of addresses announced to Internet:   2669487108
Equivalent to 159 /8s, 29 /16s and 36 /24s
Percentage of available address space announced:   72.1
Percentage of allocated address space announced:   72.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   96.1
Total number of prefixes smaller than registry allocations:  171386

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   116903
Total APNIC prefixes after maximum aggregation:   34905
APNIC Deaggregation factor:3.35
Prefixes being announced from the APNIC address blocks:  119739
Unique aggregates announced from the APNIC address blocks:49900
APNIC Region origin ASes present in the Internet Routing Table:4917
APNIC Prefixes per ASN:   24.35
APNIC Region origin ASes announcing only one prefix:   1221
APNIC Region transit ASes present in the Internet Routing Table:852
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 25
Number of APNIC region 32-bit ASNs visible in the Routing Table:912
Number of APNIC addresses announced to Internet:  731230080
Equivalent to 43 /8s, 149 /16s and 175 /24s
Percentage of available APNIC address space announced: 85.5

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-63999, 131072-133631
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:167455
Total ARIN prefixes after maximum aggregation:83038
ARIN Deaggregation factor: 2.02
Prefixes being announced from the ARIN address blocks:   168921
Unique aggregates announced from the ARIN address blocks: 78775
ARIN Region origin ASes present in the Internet Routing Table:16215
ARIN Prefixes per ASN:  

Cogent to Comcast IPv6 broken?

[Will Orton]

Cogent from various west coast USA locations seems to have trouble getting to 
some Comcast ipv6 addresses:

Cogent LG Los Angeles to www.comcast6.net
traceroute to 2001:558:fe16:7:69:252:216:215 (2001:558:fe16:7:69:252:216:215), 
30 hops max, 80 byte packets
 1  2001:550:1:317::1 (2001:550:1:317::1)  70.184 ms  70.181 ms
 2  * *
 3  * *
 4  2001:550:4::51 (2001:550:4::51)  15.013 ms  14.981 ms
 5  * *
 6  * *
[ ... ]


Cogent LG San Francisco ipv6 trace to www.comcast6.net
 traceroute to 2001:558:fe16:7:69:252:216:215 (2001:558:fe16:7:69:252:216:215), 
30 hops max, 80 byte packets
 1  2001:550:1:31f::1 (2001:550:1:31f::1)  0.367 ms  0.369 ms
 2  * *
 3  * *
 4  * *
[ ... ]

Cogent LG San Jose ipv6 ping to www.comcast6.net
PING 2001:558:fe16:7:69:252:216:215(2001:558:fe16:7:69:252:216:215) 56 data 
bytes

--- 2001:558:fe16:7:69:252:216:215 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 13999ms


Cogent LG San Jose ipv6 ping to speedtest.comcast.net (Los Angeles does same 
thing, but Kansas City works):
PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes

--- 2001:558:fe2a:3:69:241:64:6 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 14000ms

from Los Angeles same thing, but from Cogent's LG Kansas City it works:
PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes
64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=1 ttl=55 time=35.6 ms
64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=2 ttl=55 time=35.7 ms
64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=3 ttl=55 time=35.6 ms
64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=4 ttl=55 time=35.6 ms
64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=5 ttl=55 time=35.6 ms

--- 2001:558:fe2a:3:69:241:64:6 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4043ms
rtt min/avg/max/mdev = 35.620/35.676/35.734/0.241 ms


This is similar to issues I see with a Cogent IPv6/BGP-enabled transit 
connection in Los Angeles to a random
Comcast customer address (that is otherwise up and reachable from HE.net, NTT, 
etc):

(from router with ipv6 BGP Cogent transit connection):
traceroute6 to 2601:7:1300:3d2::1 (2601:7:1300:3d2::1) from 2001:550:2:18::5:2, 
64 hops max, 12 byte packets
 1  2001:550:2:18::5:1 (2001:550:2:18::5:1)  1.903 ms  1.120 ms  10.771 ms
 2  * * *
 3  * 2001:550::57 (2001:550::57)  15.654 ms *
 MPLS Label=19852 CoS=2 TTL=255 S=0
 MPLS Label=19207 CoS=2 TTL=255 S=1
 4  * * *


I have Cogent ticket #HD005706297  on that but I'm being ignored.
I see the similar things from Cogent IP6 transit out of San Jose.

Anyone at Cogent able to look at this? I basically blackhole big chunks of 
Comcast ipv6 on my network when I 
enable ipv6 to Cogent.


-Will

Re: Requirements for IPv6 Firewalls

[Simon Perreault]

Le 2014-04-18 14:00, William Herrin a écrit :
> On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault  wrote:
>> Le 2014-04-18 13:35, William Herrin a écrit :
>>> Your document specifies "Enterprise" firewalls. Frankly I think that's
>>> wise. Consumer and enterprise users have very different needs and very
>>> different cost points.
>>
>> Over here we have no use for IPv6 NAT. We have our own PI space. I
>> suspect many other enterprises would be in a similar situation.
>>
>> I totally get your position, but I don't see how it can justify an
>> Internet-wide requirement.
> 
> As I understand your document, you're trying to scope a set of minimum
> required features for a firewall that will be able to describe itself
> as "RFC whatever compliant." The idea is for folks working for large
> enterprises to be able to use such a tag as a discriminator for
> potential purchases. Since a pretty humongous number of them are using
> NAT with IPv4 and are likely to want to do so with IPv6, leaving that
> out of the required feature list seems counter-productive to your goal
> of a document which has utility to them.
> 
> Besides, you have spam control and URL filtering in there. Do you
> seriously propose that spam control and URL filtering rank above NAT
> on the *firewall* requirements list?

Well, it's not *my* document, but I'm very interested in it.

IMHO it should not be a shopping list of features that people might
want. The goal should not be to be a base for RFPs.

IMHO, what the IETF can do is recommend a set of behavioural traits that
make IPv6 firewalls behave like good citizens in the Internet ecosystem.
Meaning that a firewall that obeys those requirements will not break the
Internet. For example, passing ICMPv6 Too Big messages is important to
not break the Internet.

I think we can get consensus on such requirements, and I think it would
fit the IETF's role. A feature shopping list, not so much.

Simon

Re: Requirements for IPv6 Firewalls

[Gary Buhrmaster]

On Fri, Apr 18, 2014 at 3:02 PM, William Herrin  wrote:

> The main drivers behind the desire for NAT in IPv6 you've heard
> before, but I'll repeat them for the sake of clarity:

5. Some industries (PCI compliance) *require* NAT as part of
the audit-able requirements.  Yes, that should get changed.
But until it does, (at least some) enterprises are going to
be between a rock and a hard place.

As Bill says, the place to get this fixed is not to tell the
enterprises they are doing it wrong, but to change the
requirements that auditors measure against.  I would cheer
the effort to engage those bodies to get them to understand
that NAT is not the way (for it is not).  This does not mean
ignore the problem.  It does not mean to tell people they
are doing it wrong.  It means active engagement with such
organizations.  And it is hard, policy type, work,

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault  wrote:
> Le 2014-04-18 13:35, William Herrin a écrit :
>> Your document specifies "Enterprise" firewalls. Frankly I think that's
>> wise. Consumer and enterprise users have very different needs and very
>> different cost points.
>
> Over here we have no use for IPv6 NAT. We have our own PI space. I
> suspect many other enterprises would be in a similar situation.
>
> I totally get your position, but I don't see how it can justify an
> Internet-wide requirement.

As I understand your document, you're trying to scope a set of minimum
required features for a firewall that will be able to describe itself
as "RFC whatever compliant." The idea is for folks working for large
enterprises to be able to use such a tag as a discriminator for
potential purchases. Since a pretty humongous number of them are using
NAT with IPv4 and are likely to want to do so with IPv6, leaving that
out of the required feature list seems counter-productive to your goal
of a document which has utility to them.

Besides, you have spam control and URL filtering in there. Do you
seriously propose that spam control and URL filtering rank above NAT
on the *firewall* requirements list?

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[Mike Hale]

Many enterprises probably are in the same position, but a whole lot of
them aren't.

Maybe this comes down to "should" versus "must".  I don't think all
IPv6 firewalls "must" support NAT, but they should.

On Fri, Apr 18, 2014 at 10:40 AM, Simon Perreault  wrote:
> Le 2014-04-18 13:35, William Herrin a écrit :
>>> Does that mean all IPv6 firewalls should support NAT?
>>>
>>> Remember, we're aiming for a base set of requirements applying to all
>>> IPv6 firewalls.
>>
>> Your document specifies "Enterprise" firewalls. Frankly I think that's
>> wise. Consumer and enterprise users have very different needs and very
>> different cost points.
>
> Over here we have no use for IPv6 NAT. We have our own PI space. I
> suspect many other enterprises would be in a similar situation.
>
> I totally get your position, but I don't see how it can justify an
> Internet-wide requirement.
>
> Simon
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]

[Mike A]

On Mon, Apr 14, 2014 at 10:09:14PM +, Matthew Black wrote:
> IIRC, the message was sent via courier instead of cable or telephone to
> prevent interception. Did the military not even trust its own cryptographic
> methods? Or did they not think withdrawal of the Japanese ambassador was not
> very critical?

The message was sent by Western Union. There being no cable between the
Hawaiian Islands and the mainland at the time, the message went by commercial
radio, in plaintext, and thence by civilian bicycle messenger (of Japanese
ancestry, as it happened) to Fort Shafter, where it was read while the attack
was in progress.

David Kahn's fine book, _The Codebreakers_, discusses this in rather more
detail. I recommend the original version; the paperback and later hardback
editions contain rather less meat.

-- 
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin 

Re: Requirements for IPv6 Firewalls

[Simon Perreault]

Le 2014-04-18 13:35, William Herrin a écrit :
>> Does that mean all IPv6 firewalls should support NAT?
>>
>> Remember, we're aiming for a base set of requirements applying to all
>> IPv6 firewalls.
> 
> Your document specifies "Enterprise" firewalls. Frankly I think that's
> wise. Consumer and enterprise users have very different needs and very
> different cost points.

Over here we have no use for IPv6 NAT. We have our own PI space. I
suspect many other enterprises would be in a similar situation.

I totally get your position, but I don't see how it can justify an
Internet-wide requirement.

Simon

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 1:15 PM, Timothy Morizot  wrote:
> On Apr 18, 2014 10:04 AM, "William Herrin"  wrote:
>> That's correct: you don't understand. Until you do, just accept: there
>> are more than a few folks who want to, intend to and will use NAT for
>> IPv6. They will wait until NAT is available in their preferred
>> products before making any significant deployment efforts.
>
> Actually, the few like you will hold off until they are behind the curve,
> then scramble to catch up. Good luck with that strategy!

You know, you zealots are playing this stupid. You've already won: no
NAT in consumer devices means that when (if) IPv4 starts its decline,
nat traversal will leave consumer-focused software. And sooner or
later there will be a consumer app that business has to have.

The only way you can snatch defeat from the jaws of victory is if IPv6
fails to launch. Look around you. IPv6 use on the Internet, actual
use, is still barely in the single digits. If you let us get used to
extending IPv4 with carrier NAT, markets and so on you lose
everything. And if you think the math says that can't happen, you
badly underestimate folks' ingenuity.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 1:31 PM, Simon Perreault  wrote:
> Le 2014-04-18 13:25, Mike Hale a écrit :
>> I agree with Bill.  You can poopoo NAT all you want, but it's a fact
>> of most networks and will continue to remain so until you can make a
>> compelling case to move away from it.
>
> Does that mean all IPv6 firewalls should support NAT?
>
> Remember, we're aiming for a base set of requirements applying to all
> IPv6 firewalls.

Your document specifies "Enterprise" firewalls. Frankly I think that's
wise. Consumer and enterprise users have very different needs and very
different cost points.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[Simon Perreault]

Le 2014-04-18 13:25, Mike Hale a écrit :
> I agree with Bill.  You can poopoo NAT all you want, but it's a fact
> of most networks and will continue to remain so until you can make a
> compelling case to move away from it.

Does that mean all IPv6 firewalls should support NAT?

Remember, we're aiming for a base set of requirements applying to all
IPv6 firewalls.

Simon

Re: Requirements for IPv6 Firewalls

[Mike Hale]

Depends on your definition of "behind the curve".  You could make the
argument that folks who aren't IPv6 ready now are behind the curve.  A
weak argument considering IPv4 works perfectly fine for those of
'behind the curve'.

I agree with Bill.  You can poopoo NAT all you want, but it's a fact
of most networks and will continue to remain so until you can make a
compelling case to move away from it.

On that note, it's awesome that Fernando is seeking feedback this
early in the game.  Kudos to you sir.

On Fri, Apr 18, 2014 at 10:15 AM, Timothy Morizot  wrote:
> On Apr 18, 2014 10:04 AM, "William Herrin"  wrote:
>> That's correct: you don't understand. Until you do, just accept: there
>> are more than a few folks who want to, intend to and will use NAT for
>> IPv6. They will wait until NAT is available in their preferred
>> products before making any significant deployment efforts.
>
> Actually, the few like you will hold off until they are behind the curve,
> then scramble to catch up. Good luck with that strategy!



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: Requirements for IPv6 Firewalls

[Timothy Morizot]

On Apr 18, 2014 10:04 AM, "William Herrin"  wrote:
> That's correct: you don't understand. Until you do, just accept: there
> are more than a few folks who want to, intend to and will use NAT for
> IPv6. They will wait until NAT is available in their preferred
> products before making any significant deployment efforts.

Actually, the few like you will hold off until they are behind the curve,
then scramble to catch up. Good luck with that strategy!

Re: Requirements for IPv6 Firewalls

[William Herrin]

On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu  wrote:
> On Thu, Apr 17, 2014 at 11:45 PM, George Herbert 
> wrote:
>> You are missing the point.
>>
>> Granted, anyone who is IPv6 aware doing a green-field enterprise firewall
>> design today should probably choose another way than NAT.
>>
>
> That's why you have gazzilions of IP addresses in IPv6, so you don't need to
> NAT anything (among other things). I don't understand why people cling to
> NAT stuff when you can just route.

Hi Eugeniu,

That's correct: you don't understand. Until you do, just accept: there
are more than a few folks who want to, intend to and will use NAT for
IPv6. They will wait until NAT is available in their preferred
products before making any significant deployment efforts.

The main drivers behind the desire for NAT in IPv6 you've heard
before, but I'll repeat them for the sake of clarity:

1. Easier to manage the network if the IPv4 and IPv6 versions are
identical but for the IP addresses. Would've been even easier if the
IP addresses were identical too, but that ship sailed more than a
decade ago.

2. Risk management - developing a new operating posture for a new
protocol is high risk. Translating the existing posture is lower risk.
In most places the existing posture includes extensive NAT. The number
of IPv4 networks in which no NAT is employed is vanishingly small.

3. Renumbering - works about as well in IPv6 as in IPv4, which is to
say badly. And doubling down on the addresses assigned to hosts is
still half baked -- a worthwhile idea but needs more time in the
kitchen.

4. Defense in depth is a core principle of all security, network and
physical. If you don't practice it, your security is weak. Equipment
which is not externally addressable (due to address-overloaded NAT)
has an additional obstruction an adversary must bypass versus an
identical system where the equipment is externally addressable (1:1
NAT, static port translation and simple routing). This constrains the
kinds of attacks an adversary may employ.


Feel free to refute all four points. No doubt you have arguments you
personally find compelling. Your arguments will fall on deaf ears. At
best the arguments propose theory that runs contrary to decades of
many folks' experience. More likely the arguments are simply wrong.

Either way, you need NAT in the firewall products or you need some
miracle application, the desire for which compels folks to move past
the rationale above. Do you see the latter happening any time soon?
Neither do I.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

[Nick Hilliard]

On 18/04/2014 01:51, Matthew Kaufman wrote:
> While you're at it, the document can explain to admins who have been
> burned, often more than once, by the pain of re-numbering internal
> services at static addresses how IPv6 without NAT will magically solve
> this problem.

it's magic.  There's no need to explain, silly!

Nick

Re: EIGRP support !Cisco

[Laurent Vanbever]

Hi folks,

A bunch of collaborators and I worked on the problem of IGP 
migration/reconfiguration before. Basically, we augmented Vijay’s methodology 
to guarantee its correctness. Indeed, when you start flipping Administrative 
Distance (AD) between IGP1 and IGP2, bad stuff (i.e., forwarding loops, BGP 
oscillations) can happen if you’re not careful. Also, what Vijay describes is a 
migration between two Link State (LS) protocols (in this case, OSPF to ISIS). 
Migrating from EIGRP to a LS has to be treated differently since EIGRP is a 
Distance Vector (DV) protocol: when you flip the AD on router X, routing 
decisions at router Y can be impacted (this was not the case in the AOL 
migration). Fortunately, we managed to get that case covered to.

If you’re interested in knowing more, we covered the LS-to-LS migration case in 
“Seamless Network-Wide IGP Migrations” (see 
http://vanbever.eu/pdfs/vanbever_igpmig_sigcomm_2011.pdf). Our work about 
DV-to/from-LS is not published yet, but I’d be happy to share it privately 
(just ping me).

Also, something to keep in mind when you start messing with an IGP: usually, 
there is BGP running on top of it… And changing the IGP can make BGP decisions 
go crazy (the decision process rely on IGP cost). We described this in another 
work “When the Cure is Worse than the Disease: the Impact of Graceful IGP 
Operations on BGP” (http://vanbever.eu/pdfs/vanbever_igp_bgp_infocom_2013.pdf).

Nick, I’d be happy to chat OOB if you want to know more or go further with this 
migration.

Cheers,
— Laurent


On Jan 24, 2014, at 8:04 AM, Jimmy Hess  wrote:

> On Fri, Jan 10, 2014 at 9:57 AM, Christopher Morrow > wrote:
> 
>> On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard  wrote:
>>> On 08/01/2014 18:14, Christopher Morrow wrote:
 question... there's people that have done this before even :)
>>> https://www.nanog.org/meetings/nanog29/presentations/gill.pdf
>> 
>> oh yea! that guy! I hear he's done this sort of thing a few times
>> now... probably has practice and tools and stuff :)
>> 
> 
> Hey... Tools why not...   Control+Click...  select all the routers
> Right click   "Upgrade IGP to ISIS"
> 
> Go grab a drink...   Come back...  "Done"  click OK.  No more Eigrp.
> 
> I suppose  PuTTy / SecureCRT haven't added the feature yet...
> perhaps in a few releases?  :)
> 
> 
> -- 
> -JH

Re: Requirements for IPv6 Firewalls

[Enno Rey]

Hi,

On Fri, Apr 18, 2014 at 04:57:57PM +1000, Matt Palmer wrote:
> On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote:
> > On Apr 17, 2014 7:52 PM, "Matthew Kaufman"  wrote:
> > > While you're at it, the document can explain to admins who have been
> > burned, often more than once, by the pain of re-numbering internal services
> > at static addresses how IPv6 without NAT will magically solve this problem.
> > 
> > If you're worried about that issue, either get your own end user
> > assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix
> > translation) at the perimeter. That's not even a hard question.
> 
> Why use NAT-PT in that instance?  Since IPv6 interfaces are happy running
> with multiple addresses, the machines can have their publically-accessable
> address and also their ULA address, with internal services binding to (and
> referring to, via DNS, et al) the ULA address

there's two problems with that approach:

a) what is "an internal service"? In a world of complex data center 
environments running/offering all types of services to various parties ($ORG's 
employees, business partners, customers and closed groups from customers, 
"public"/Internet) you can't make that distinction any longer. And even if you 
could, latest trying to reflect that distinction in your DNS setup will screw 
you. At the end of the day you'll still end up in "address selection hell".

b) from my operational experience address selection is still a "hugely 
unresolved problem", despite RFC 3484 and RFC 6724. 
As long as this (problem) persists, from our perspective there's a simple 
recommendation/solution: "when there's a [continued] decision problem, just 
don't offer a choice". Read, in IPv6 context: "go with GUAs only and only one 
per interface".

best

Enno


-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

Re: Requirements for IPv6 Firewalls

[Enno Rey]

Hi,

On Thu, Apr 17, 2014 at 06:55:24PM +0200, Sander Steffann wrote:
> Hi Bill,
> 
> > Also, I note your draft is entitled "Requirements for IPv6 Enterprise
> > Firewalls." Frankly, no "enterprise" firewall will be taken seriously
> > without address-overloaded NAT. I realize that's a controversial
> > statement in the IPv6 world but until you get past it you're basically
> > wasting your time on a document which won't be useful to industry.
> 
> I disagree. While there certainly will be organisations that want such a 
> 'feature' it is certainly not a requirement for every (I hope most, but I 
> might be optimistic) enterprises.

I fully second Sander's input. I've been involved in IPv6 planning in a number 
of very large enterprises now and _none_ of them required/asked for 
(66/overloading) NAT for their firewall environments. A few think about very 
specific deployments of NPTv6 like stuff for connections to supplier/partner 
networks (to map those to their own address space) but these are corner cases 
not even relevant for their "firewalls".

best

Enno

 




> 
> Cheers,
> Sander
> 
> 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Thu, Apr 17, 2014 at 11:45 PM, George Herbert
wrote:

>
>
>
> On Thu, Apr 17, 2014 at 11:32 AM, Eugeniu Patrascu wrote:
>
>> ...
>> It's a bigger risk to think that NAT somehow magically protects you
>> against
>> stuff on the Internet.
>> Also, if your problem is that someone can screw up firewalls rules, then
>> you have bigger issue in your organization than IPv6.
>
>
>
>> There's a fair argument to be made which says that kind of NAT is
>> > unhealthy. If its proponents are correct, they'll win that argument
>> > later on with NAT-incompatible technology that enterprises want. After
>> > all, enterprise security folk didn't want the Internet in the
>> > corporate network at all, but having a web browser on every desk is
>> > just too darn useful. Where they won't win that argument is in the
>> > stretch of maximum risk for the enterprise security folk.
>> >
>> >
>> Any technology has associated risks, it's a matter of how you
>> reduce/mitigate them.
>> This paranoia thingie about IPv6 is getting a bit old.
>> Just because you don't (seem to) understand how it works, it doesn't mean
>> no one else should use it.
>
>
>
> You are missing the point.
>

> Granted, anyone who is IPv6 aware doing a green-field enterprise firewall
> design today should probably choose another way than NAT.
>
>
That's why you have gazzilions of IP addresses in IPv6, so you don't need
to NAT anything (among other things). I don't understand why people cling
to NAT stuff when you can just route.



> What you are failing is that "redesign firewall rules and approach from
> scratch along with the IPv6 implementation" usually is not the chosen path,
> versus "re-implement the same v4 firewall rules and technologies in IPv6
> for the IPv6 implementation", because all the IPv6 aware net admins are
> having too much to do dealing with all the other conversion issues, vendor
> readiness all across the stack, etc.
>
>
You treat IPv6 like the only protocol running and design the implementation
taking that into consideration. Where necessary you publish  records
and so only devices/services that are IPv6 aware will be accessed over
IPv6, all others can stay on IPv4 until they are migrated. It works
wonderful.

This idea of matching IPv4 1:1 to IPv6 is not the way to go.


> Variations on this theme are part of why it's 2014 and IPv6 hasn't already
> taken over the world.  The more rabid IPv6 proponents have in fact shot the
> transition in the legs repeatedly, and those of us who have been on the
> front lines would like you all to please shut up and get out of the way so
> we can actually finish effecting v6 deployment and move on to mopping up
> things like NAT later.
>


I don't get this paragraph. From my perspective, if you want IPv6 you can
do it. From all the organizations I get in contact and ask about IPv6 is
the lack of knowledge and interest that puts a stop to the deployment,
nothing else.

Eugeniu

Re: Requirements for IPv6 Firewalls

[Seth Mos]

On 18-4-2014 8:57, Matt Palmer wrote:
> On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote:
>> On Apr 17, 2014 7:52 PM, "Matthew Kaufman"  wrote:
>>> While you're at it, the document can explain to admins who have been
>> burned, often more than once, by the pain of re-numbering internal services
>> at static addresses how IPv6 without NAT will magically solve this problem.
>>
>> If you're worried about that issue, either get your own end user
>> assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix
>> translation) at the perimeter. That's not even a hard question.
> 
> Why use NAT-PT in that instance?  Since IPv6 interfaces are happy running
> with multiple addresses, the machines can have their publically-accessable
> address and also their ULA address, with internal services binding to (and
> referring to, via DNS, et al) the ULA address; when you change providers,
> the publically-accessable address changes (whoopee!), but the internal
> service address doesn't.

Sounds good in theory, I tried it but it got ugly really fast. Before
you know it you have a layers of obfuscation, and even more work to get
it to work right. That's really not a good argument for the general IPv6
case.

Then there's the issue of making not just hosts do address selection but
bringing that down to making applications choose address selection. As a
admin I really don't want to go there. I just want a central point where
I can pass, block or redirect.

Just keep it as simple as possible, but not simpler. A host with a IPv4
and GLA IPv6 address is as complicated as you want it.

The only case I see for NPt is for cheap multi wan where you have the
primary prefix on your "LAN" and perform NPt for that prefix when it
goes out the "3G" stick. Note that you would still need the same
(delegated) prefix size on both connections (e.g. /64, /56 or /48)

What is also nice is that in the case of NPt the firewall rules for both
"WAN" and "3G" can be the same as the destination address (after
performing NPt) is still the same. "Manageable".

Kind regards,

Seth