Cupfighter.net

Day 3+4 of the V6 World 2012 Congress
were also interesting.

In many ways my conclusions of the first two conference days were reconfirmed but additionally I learned that;

1. IPv4 is here to stay and it will take many more years before IPv4 is completely history. On the other hand, it is still unpredictable when IPv4 address space is really exhausted. See Geoff Huston’s IPv4 reports. Predictions are currently somewhere later this year or perhaps 2013 or even later, depending on the demand for IPv4 addresses and the way the use for IPv6 actually evolves.
2. Any NAT technology like Carrier Grade NAT (CGN) has disadvantages to make it a viable transition mechanism. As such it is less preferred.
3. Dual stack is the preferred transition mechanism. Where the content provider or hosting party provides access to (web) services via both IPv4 as well as IPv6.
4. The sheer size of the IPv6 address space requires to get rid of the classical IPv4 thinking regarding address waste and the use of private IP addressing. These limitations simply don’t exist anymore. Currently the smallest routable IPv6 subnet is a /64 subnet which could have up to a maximum of 18,446,744,073,709,551,616 unique IPv6 addresses. Think about it; each /64 subnet is significantly larger than the existing IPv4 address space altogether!
5. If the 100 biggest web sites in the world (the likes of FB, Google, Yahoo, Amazon, Microsoft, Akamai, etc) would get accessible via IPv6, it would ensure that the world would adopt IPv6 much faster.
6. End users need to have IPv6 enabled Customer-premises equipment (CPE) such as mobile devices, DSL modems and routers, before the content providers and ISPs really would benefit the transition. Without these IPv6 enabled devices there is simply no demand for IPv6. This chicken-egg problem needs to be addressed on either side; both the ISPs as well as content providers needs to provide IPv6 solutions to address the IPv4 exhaustion and global expansion of Internet enabled devices.
7. If vendors say that they are IPv6 ready, do not take this for granted. Many implementations have shown (interoperability) limitations when deployed. Inform the vendor of any issues so that this gets improved.
8. Basic IP address space allocation:
   a. /32 for Schuberg Philis
   b. /48 per customer environment
   c. /64 per smallest subnet (VLAN)
   d. /127 potentially for point-to-point links (on demand, implementation specific, not internet routable)

The Dual stack mechanism
an interesting solution to implement IPv6 is providing web services in a so called ‘dual stack’ setup. This means that content is provided both via IPv4 as via IPv6. There are several dual stack scenario’s.

Tore Anderson of Redpill Linpro AS discussed the following scenario, an IPv6 centric dual stack set up, his recommendation and in his opinion most future proof:

I found this an interesting view as it emphasizes on the majority of components within an IT (hosting) environment being IPv6 configured but only a small part of it being IPv4 capable. This scenario would lead to a more future proof set up, focusing on the phase out of IPv4 altogether.

A bogon is a …
Something I also learned but until this conference I’ve never heard of before, is a so called bogon.

It’s wikipedia definition is:

“a bogus IP address, and an informal name for an IP packet on the public Internet that claims to be from an area of the IP address space reserved, but has not yet been allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR).”

I actually found this quite funny because I’ve been around in this industry for some time now so I was somewhat surprised that I haven’t heard of this word before.

All in all,
This was a very interesting conference where I learned that IPv6 is inevitable and that the momentum is now to prepare for it. 6 June 2012 is the day to mark your agenda; it will be the day when IPv6 will permanently be turned on by many internet (content) providers.

Don Lee from Facebook and author of the Cisco Press book “Enhanced IP Services for Cisco Networks” argued; “It’s our job as IT professionals to make the transition to IPv6 as smooth as possible. The end users should not bother about it, much less as they bother nowadays about IPv4.”

And as Paul Zawacki, Enterprise Architect at Oracle so eloquently put; “IPv6 is a giant leap in IT evolution. It might very well be the most challenging moment in your professional career.”

I feel that these remarks are no understatements… Do you?

A marathon day
Day 2 of the IPv6 conference was actually pretty good. It was a ‘marathon’ day of +10hrs of presentations and panel discussions. Unfortunately during the last ‘talking heads’ sessions the best part of me already left the building and concentration dropped. Nonetheless it was a good day and the welcome drinks+bites at the end of the day were rewarding

The opening speech
was done by John Curran, the founder and president of ARIN (the American Internet Registrar, the equivalent of the European RIPE organization). John was involved in IPng the early RFCs of what eventually became known as IPv6. How cool is that!?

My colleague Erwin Blekkenhorst (maintainer of IPv6.net) also tweeted a lot of interesting remarks and sound bites. Follow ‘@ipv6dotnet’ for getting those tweets.

During the panel discussions several companies shared their views and experiences on the IPv6 implementation and IPv4 to IPv6 transition. Better said co-existence or ‘dual stack’ providing your services via IPv4 and IPv6 in parallel.

I will not bore you with an exhaustive summary (send me a message and I will) of each presentation but I’d like to condense it into a) it’s interesting and worthwhile being at this conference and b) I feel that this is the environment were ‘it’ actually happens; the Internet industry adopting IPv6.

My conclusions
of the second day would be:

1. Moving from IPv4 to IPv6 is inevitable. Not being part of it is basically ‘missing the boat’ and loosing the competitive advantage.
2. Be prepared before actually implementing IPv6. Have a sound strategy resp implementation plan.
3. Implementing IPv6 is a ‘journey‘. Take it on a step by step basis and learn as you go and grow.
4. Despite many (hw or sw) vendors say that they support IPv6 they do not always interact as you’d expect.
5. So in addition; try before you die (i.e. perform a POC ensuring that your design is providing what you aim for. Feed the findings back to the hw/sw vendors.
6. Expect to spend a lot of time on awareness and training. Knowledge on IPv6 is the critical success factor.
7. From a Schuberg Philis IPv6 Task Force perspective we seem to be aligned with what the industry as a whole is doing; we are part of the IPv6 community for some time now and are already enabled on connectivity level. Application layer IPv6 is our next challenge.
8. I believe it is important that Schuberg Philis and our customers who are able to participate are part of the IPv6 World Day June 6, 2012. Let’s go for it!
   The FUTURE is NOW!

I’m visiting the V6 World Congress 2012 together with collegue Erwin Blekkenhorst (a long time IPv6 adept and owner of ipv6.net as well as its corresponding Facebook web page). This IPv6 congress is held Feb 7-10 in Paris, France.

Central question of this congress is: “Enterprises Migration: How and When?”

Amongst others, both Erwin and me are IPv6 task force members within Schuberg Philis and we are determined to increase the IPv6 awareness with our fellow collegues and our customers. The questions we would like to address are: How will it impact us, our business and what will it mean to our customers, what are the ways to ‘migrate’ safely from IPv4 to IPv6 resp to operate a dual stack setup?

On this blog I’ll be posting our experiences and impressions of this congress on a day-to-day basis.

Day 1 – Technical Tutorial Day – Tue Feb 7th

The Cisco ASA firewall offers protection for Denial of Service attacks, such as SYN floods, TCP excessive connection attacks etc.
With the Policy Framework functionality, you can configure granular controls for TCP Connection limits and timeouts. For example, you can control and limit the maximum number of simultaneous TCP and UDP connections that are allowed towards a specific host (or subnet), the maximum number of simultaneous embryonic connections allowed (for SYN flood attacks), the per-client max number of connections allowed etc.

STEP1: Identify the traffic to apply connection limits using a class map
ASA(config)# access list CONNECTIONS-ACL extended permit ip any 10.1.1.1 255.255.255.255
ASA(config)# class-map CONNECTIONS-MAP
ASA(config-cmap)# match access-list CONNECTIONS-ACL

STEP2: Add a policy map to set the actions to take on the class map traffic
ASA(config)# policy-map CONNECTIONS-POLICY
ASA(config-pmap)# class CONNECTIONS-MAP
! The following sets connection number limits
ASA(config-pmap-c)# set connection {[conn-max n] [embryonic-conn-max n]
[per-client-embryonic-max n] [per-client-max n] [random-sequence-number {enable | disable}]}

The conn-max n argument sets the maximum number of simultaneous TCP and/or UDP connections that are allowed, between 0 and 65535.
The embryonic-conn-max n argument sets the maximum number of simultaneous embryonic connections allowed, between 0 and 65535.
The per-client-embryonic-max n argument sets the maximum number of simultaneous embryonic connections allowed per client, between 0 and 65535.
The per-client-max n argument sets the maximum number of simultaneous connections allowed per client, between 0 and 65535.

! The following sets connection timeouts
ASA(config-pmap-c)# set connection timeout {[embryonic hh:mm:ss] {tcp hh:mm:ss
[reset]] [half-closed hh:mm:ss] [dcd hh:mm:ss [max_retries]]}

STEP3: Apply the Policy on one or more interfaces or Globaly
ASA(config)# service-policy CONNS-POLICY {global | interface interface_name}

The IP audit feature provides basic IPS support for the ASA. It supports a basic list of signatures, and you can configure the ASA to perform one or more actions on traffic that matches a signature.

STEP:1 To define an IP audit policy for informational signatures
ASA(config)# ip audit name policy_name info [action [alarm] [drop] [reset]]

STEP:2 To define an IP audit policy for attack signatures
ASA(config)# ip audit name policy_name attack [action [alarm] [drop] [reset]]

Where alarm generates a system message showing that a packet matched a signature, drop drops the packet, and reset drops the packet and closes the connection. If you do not define an action, then the default action is to generate an alarm.

STEP:3 To assign the policy to an interface
ASA(config)# ip audit interface interface_name policy_name

STEP:4 To disable signatures
ASA(config)# no ip audit signature [signature]

A few days ago while starting TortoiseSVN it prompted me to update to version 1.7

After I updated to version 1.7. I could not connect to our internal repository anymore. The connection failed with the following error: SSL error: sslv3 alert certificate unkown.

SSL error: sslv3 alert certificate unknown

Our internal respoitory is secured with a certificated issued by our internal CA infrastructure.

Root CA

|
v

Intermediate Certificate

|
v

Repository certificate

Surfing to the svn repository does not produce an error, so the certificate chain is fine. At first I figured that Tortoise was using its own certificate store, but it turns out that Tortoise does use the Windows Root CA store, so there is no need to add the Root CA.

After some more investigation we found out that Tortoise does use the Windows Root CA store to validate the certificate chain, but does not use the Intermediate CA store to complete the certificate chain, like windows does. Since all our client machines have the intermediate certificate in the Intermediate CA store we never noticed that the certificates offered by apache were not chained. After chaining the repository certificate with the intermediate certificate Tortoise was able to talk to the repository again.

The ACE has two different ways of treating the L7 connections internally, that we call “proxied” and “unproxied”. In essence, the proxied mode means that the traffic will be processed by one of the CPU (normally to inspect/modify the L7 data), while, on the unproxied mode, the ACE sets up a hardware shortcut (Fastpath) that allows forwarding traffic without the need to do any processing on it.

For a L7 connection, the ACE will proxy it at the beginning, and, once all the L7 processing has been done it will unproxy the connection to save resources until L7 processing is required again. Before it goes ahead with the unproxying, it needs to see the ACK for the last L7 data sent.
In packet captures, we see that the client is taking approximately 200ms to send this acknowledgement each time. When a connection is composed of many HTTP requests, the proxy/unproxy process can add up a total delay of several seconds.

The configuration of a sorry/backup server farm with for example a HTTP redirect to a sorry page will cause the ACE to treat the connections to the VIP as a L7 and influence the total page load time.

The proxy/unproxy delay can have a big impact for situations in which the client is taking a long time to send the acknowledgement, so, the ACE allows to change the behavior. It is possible to define a “round-trip-time” threshold so that connections from clients with a RTT value higher than the threshold are never unproxied.
You can do this by setting the threshold to 0 to ensure to keep connections always proxied. To do this, you would need to configure a parameter map like the one below and add it to the policy-map.
parameter-map type connection
set tcp wan-optimization rtt 0

Even though this setting will most likely solve the issue, it also has some drawbacks. The main one is that the ACE appliance only supports up to 256K simultaneous L7 connections in proxied state (which includes also the connections towards the servers, so, it would be 128K for client connections), so, if the amount of simultaneous connections reaches that limit, new connections would be dropped. The second issue, although not so impacting, would be that the maximum number of connections per second supported would also go down slightly due to the increased processing needed.

http://dnssec-debugger.verisignlabs.com/
http://dnsviz.net/

There are many concerns these days on security when taking services from cloud providers. All the areas where Schuberg Philis is actively being audited on, are area’s of concerns for IT managers.

How do I know my cloud service is being hacked and abused if it is not running inside my datacenter? What possibilities do I have to check if my employees are acting along the lines of my Acceptable Use policy? Where are the logs of that abuse, and how can I trust the logs? How do I know that my data is not copied elsewhere in the cloud, and analysed offline by my competitor?

With regards to cloud storage, the CDMI (Cloud Data Management Interface) is trying to address some of the questions, but is only one step forward.

Cloud service providers still have a long way to go. An initiative like Eurocloud  is doing great work in paving the road to trust in cloud service providers.

When cloud service providers will be able to succesfully address the concerns, they have a big advantage over the classical IT model of running your own IT: they provide all the securities you would normally build and control youself, but combined with cloud advantages like fast provisioning and fast reuse of resources.

Small and medium-sized business will then be able to actually get a better and more secure service with cloud services, then what they could build and control themselves.

What does this mean for SBP? Sure there will be competition from the cloud providers. But we are nothing more than just another cloud provider. We build services for our clients with our own cloud technologies of fast provisioning, centralized log analysis, but since we build private clouds for our customers, these customers can demand tailored solutions to address their specific needs and concerns.

Cloud computing is not a threath to our business model, but is preparing the market more and more for putting commodity services in the big generic clouds, combined with the need of supporting highly tailored private clouds.

So it is time to face the fact: Schuberg Philis, the private cloud company!

Powering the cloud. Multi marketing of course, but what is happening in the storage world? What does it mean for mission critical environments? These are the questions I am hoping to get answered today and tomorrow. Currently three sessions done. 1. Introduction to Data protection by Chriss Sop, 2. Optimizing storage in a cloudy, virtualized world by The 451 Group and 3. Enterprise Tiered Storage by John Locky.

First two sessions were somewhat low quality from a contect perspective. Too basic from on technology and on new innovations. Even for me as a non engineer. The difference between full backup, incrementals and differentials is not the thing we came here for. Although i must say that merging incrementals on the back end to always have full backups available sounds interesting. Curious to see this working in real life. How transprrent will that be? Lets ask Commvault later today. And if i can find them Quest as well. Would be nice to learn a bit on automated restore testing as well. Guaranteeing back ups remains an issue. Especially on tapes.

When i get answers, you’ll probably read more about it on cf.net or twitter.

In order to have the F5 BigIP LTM announce IPv6 Router Advertisements (RA) you have to logon to the console and create the following config file:

#
# /etc/radvd.conf
#
interface [interface name]
{
AdvSendAdvert on;
MinRtrAdvInterval 5;
MaxRtrAdvInterval 10;
AdvDefaultPreference low;
AdvHomeAgentFlag off;
prefix xxxx:xxxx:xxxx::/yy
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

You have to use lower-case characters for the interface or vlan name otherwise this will not work!

Then stop the service: bigstart stop radvd
And start the service again: bigstart start radvd