Archive for February, 2010

One of the best IPsec devices I have worked with so far is Stoke. And when I am saying best I mean it in a sense of compliance, flexibility, stability and performance.

Although it has its minuses, like any device on earth, the pretty SSX-3000 solution I’ve got my hands on knew most of the Remote-Access scenarios I could think of and EAP authentication on top. Besides that, I could do my work undisturbed, while my colleagues were experimenting on their own. Why? Because of the contexts: each one of these “virtual” routers minds its own business, permitting me to play around with my stuff, while the others could work very well, without having to worry about Cristina’s ideas. Now, 240k IPsec tunnels in remote-access with EAP authentication versus Radius and support for digital certificates sounds pretty good if you were to ask me. Mwell…not good enough for the Stoke guys…it seems. So they came up with an even more interesting idea: LAN-to-LAN. Now..hmm..this powerful machine, able of doing so much on RA…could it also be doing site-to-site? So, I’ve contacted my favorite Japanese techie and asked for instructions.

This is the way it works:

Let’s assume there are 2 security gateways, Tokyo (10.1.1.2) and Bucharest (10.1.1.1). Tokyo gateway protects a network (5.1.1.0/24), while in Bucharest we have another network (6.1.1.0/24). Stoke has the concept of “tunnel-enabled interface”, which is a only /32 IP address of an interface type “tunnel”. The following services are not allowed on a tunnel-enabled interface: static IP hosts, ARP, and routing protocols.

So, in our case, let’s assume the tunnel interface for Tokyo is 9.9.9.1/32 and for Bucharest it is 9.9.9.2/32.

As everything on an SSX is done via a context, let’s assume that Tokyo has a context called TB1 and Bucharest has a context called BT1, on which they have this LAN-to-LAN configuration. The configuration on Tokyo would look something like this:

context TB1

interface Tokyo-LAN

arp arpa

ip address 5.1.1.0/24

exit

interface Tokyo-Bucharest

arp arpa

ip address 10.1.1.2/24

exit

interface Tokyo-Tunnel tunnel

ip address 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Tokyo-Bucharest-TUN type ipsec protcol ip44 context TB1

enable

ip local 10.1.1.2 remote 10.1.1.1

bind interface Tokyo-Tunnel TB1

ip route 6.1.1.0/24

ip route 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 1/1

bind interface Tokyo-LAN TB1

exit

enable

exit

port ethernet 1/0

bind interface Tokyo-Bucharest TB1

exit

service ipsec

enable

exit

While the Bucharest config should be like this:

context BT1

interface Bucharest-LAN

arp arpa

ip address 6.1.1.0/24

exit

interface Bucharest-Tokyo

arp arpa

ip address 10.1.1.1/24

exit

interface Bucharest-Tunnel tunnel

ip address 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Bucharest-Tokyo-TUN type ipsec protcol ip44 context BT1

enable

ip local 10.1.1.1 remote 10.1.1.2

bind interface Tokyo-Tunnel TB1

ip route 5.1.1.0/24

ip route 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 2/1

bind interface Bucharest-LAN BT1

exit

enable

exit

port ethernet 2/0

bind interface Bucharest-Tokyo BT1

exit

service ipsec

enable

exit

To verify the config, run:

Stoke [TB1]# sh ike-session list

—————————————————————————-

SLOT : 1
Session Handle : f4100214
IKE Version : 2 <LAN<->LAN>
Remote IP : 10.1.1.1
IKE-SA ID : 10.1.1.1
Session State : IPSEC-ESTABLISHED, IKE-SA DONE, CHILD-SA MATURE
——————————————————————————-
While
Stoke[TB1]#sh ike-session detail handle f4100214
displays a lot of details about this session, like ports, type of authentication, lifetime values and algorithms.

Stoke[local]#sh tun
Name CctHdl Type Admin State
—————————— ——– ———- ——- ———–
Tokyo-Bucharest-TUN ce000013 ipsec:ip44 enable up
Bucharest-Tokyo-TUN ce000014 ipsec:ip44 enable up
2 objects displayed.
Stoke[local]#sh tun name Tokyo-Bucharest-TUN
will display the details of this particular tunnel.
For the moment, afaik, this is only IPv4-over-IPv4, but I can’t hardly wait to have another e-mail from these guys saying that I can also play with mixed transport on one of their new StokeOSes. 😀

Advertisements

things to remember

Posted: February 24, 2010 in technical
Tags: , ,

I used to think that, once I’ve learned…till a certain reasonable point, the IPsec protocol, how hard could another tunneling protocol be? Well…rules to remember:

1. Never say “how hard can it be”

2. Never think about eGTP as “just another tunneling protocol”

Why? Because there are A LOT of acronyms and because there is A LOT of logic behind the protocol, the messaging scheme and the entities involved.

First of all, in order to be able to take a look anytime at the acronyms themselves, along with a short explanation of their meaning and a nicely reference to the most appropriate Technical Spec that describes the term in question, I use this:

LTE – A Pocket Dictionary of Acronyms

Also, the Tech-Invite.com has a very nice list of the 3GPP TSs, classifying them by feature:

So far, I am constantly using the TS 23.xxx series, where the functions and different behaviors and scenarios are described in detail, with cool message exchange diagrams and funky references for every term.

For my PhD paper I am using the TS 33.xxx series, which describe the security aspects of the SAE/EPS implementation.

All the TSs, per releases and per versions could be found at:

http://www.3gpp.org/ftp/Specs/

My general feeling so far about these TSs is that RFCs are waaaay prettier now 😀

Sarah Brightman – tipa aia care canta alaturi de Andrea Bocelli “Time to say goodbye”, se pare ca a luat-o pe urmele Tarjei Turunen. De curand am vazut clipul Fleurs du Mal, in care soprana canta alaturi de o orchestra, un cor si o trupa de roackeri.

Desi inregistrarea din link-ul de mai jos nu e grozava, interpretarea mi se pare extraordinara. Iar gestul sopranei demonstreaza inca o data, daca mai era nevoie, ca black/heavy/<any>metal-ul si muzica simfonica sunt 2 tovarasi care fac o pereche minunata.

Fleurs du Mal

Invite to Technical…stuff

Posted: February 22, 2010 in technical
Tags: , , , , ,

I am inviting you to visit one of my favorite sites:

http://tech-invite.com/ — no longer valid

http://www.in2eps.com/3g0/tk-3gpp-netarch-108.html

The reason this is one of my favorite sites is that it is, firstly, VERY TECHNICAL 😛 of course. There are several sections where the articles are placed: Organizations, Standardization work, IETF topics, 3GPP topics, ETSI topics and…Other topics. I have to thank my VoIP guru colleague Alin for telling me about this site.

To be honest, I’ve never used any other categories, other than 3GPP and IETF topics. But these ones I have used extensively. Ranging from packet by packet IPsec negotiation, to SIP headers description, example, and a lot of scenarios, database infrastructure to UMTS and SAE architecture and scenarios, with a very welcome RFC and TS classification, I believe this site is one of the best locations where one could go to clarify technical things, to view scenarios and to take a look at packets and headers along with their analysis.

The latest link I’ve used is a secure SIP basic call from roaming, using the IMS architecture over UMTS. There are diagrams with each step of the flow, the packet dump and explanations for each packet. Gold, I say 🙂

So take a look.

Screen-shot-2010-02-22-at-10.56.00-PM1

lume, lume, hai la concurs

Posted: February 22, 2010 in technical
Tags: ,

Este vorba de Wikipedia RO – concurs de articole.

Cum se face?

Voi, oamenii cunoscatori pe o tema din domeniul Stiinta, Arta sau Societate, impartasiti cunostintele voastre cu toti cititorii Wikipedia-RO printr-un articol pe acea tema. Articolul trebuie sa fie in romana, evident, iar ca sa participati la concurs, trebuie scris in perioada 1-31 martie.

Concursul are 9 premii sub forma de medalie, si un premiu special. Iar cei care doresc sa contribuie cu premii pentru castigatori, pot face si acest lucru. Link-ul este cel de mai jos:

http://ro.wikipedia.org/wiki/Wikipedia:Concurs_de_scriere

Eu tot ma laud ca stiu IPsec, asa ca am fost provocata la a scrie un articol pe aceasta tema. Imi propun sa incerc, sa vedem ce iese. Si, mai ales…sa vedem ce adversari apar la tema asta >:)

“Well, as we have talked about QoS, why not try to see it at work?”

“Good idea!” – says I 😛

So, let’s take a look at the way 3GPP guys thought of a Dedicated Bearer creation. First of all, these dedicated bearers are structures that:

– have a specific QoS level

– unlike the default bearers, they can be both GBR and non-GBR (but not in the same time, of course) – default bearers can only be non-GBR (as per TS23.401)

– they should only be initiated from the APN, when a bearer is needed in order to send/receive data to/from a specific UE – actually, there is a Bearer Resource Command sent by the MME to the SGW on the S11 – GTP-C interface, which, if the SGW (after asking PCRF), is permitted, receives a Create Bearer Request message on the same S11 GTP-C interface. The MME forwards the Bearer Setup Request/Session Management Request to the eNB (on the S1 interface) – which verifies and deals with the resource allocation, exchanging RRC Connection Configuration messages with the UE. Once the eNB confirms the UE has enough resources to deal with another bearer, it informs the MME about this also, sending it a Bearer Setup Response/Session Management Response, which MME forwards to the SGW as a Create Bearer Response message… Pretty much what the following picture says:

1

Looking at the S11 interface that I particularly fancy, the first message of interest is the Bearer Resource Command, which has the headers described below. I am omitting the Flags header and any other header that has values described so far in the previous posts…

Procedure Transaction ID : the ID of the transactions – new concept that appears now (here is 1)

EBI – EPS Bearer ID : 5 is here ( should be between 5 and 15 – as you know, at most 11 bearers per UE)

TAD – Traffic Aggregation Description: one of its fields is Operation Code, which, here, is set to Create New TFT, as the output of this transaction will be the creation of a new bearer, with an associated TFT

*** Second to think about stuff: When the PGW intends to create a new bearer (which must have attached a new TFT), it does so based on existing QoS rules on the PCRF. Well, those rules are defined on a per port basis, which means that PGW knows what type of traffic it should transport. And so do UE and MME when sending this command. So, assuming that the traffic triggering my bearer creation is HTTP only, the TFT will need to have a single TFT Filter, on port 80 as a Single Remote Port Type. Assuming that I am intending to send FTP only, the TFT will still have a single TFT Filter, but there will be a Remote port range low limit numberof 20 and a Remote port range high limit of 21. Should I want to send both FTP and HTTP, there will be 2 TFT Filters.

Flow QoS: this one sets the values requested by the MME for the following parameters:

QCI – QoS Class Identifier – belongs to [1..255] – here is 3

MBR-U – Maximum Bit Rate for Uplink

MBR-D – Maximum Bit Rate for Downlink

GBR-U – Guaranteed Bit Rate for Uplink

GBR-D – Guaranteed bit Rate for Downlink

The reply from the SGW on this message is the Create Bearer Request from the SGW, which asks the MME to start the negotiation with the eNB in order to allocate resources for this bearer:

– it keeps the same EBI – 5 here

– it also keeps the Transaction ID – 1 here

– and the Bearer Context looks like this:

— EBI – same : 5

— Charging ID : if needed – here 0

— F-TEID of the S1 GTP-U interface of the SGW (!!! Remember that SGW has GTP-C _and_ GTP-U on its interface – which can be a single IP or different IP addresses-recommended – GTP-C does with MME and GTP-U does with eNB – in here it negotiates the GTP-U interface that the eNB will use to send data plane traffic on )

— F-TEID of the S5/S8 GTP-U interface of the SGW – which is headed towards the PGW – may be the same as the previous one or a different one

— Bearer QoS : which holds our beloved QoS values described in the previous eGTP post:

—– the QCI, MBR-U, MBR-D, GBR-U and GBR-D described above

—– the ARP – Allocation&Retention Priority

*** Please read TS23.401 – starting with page 38… Basically, this ARP should be interpreted as “The Priority of Allocation and Retention” – meaning this is a bearer prioritizer: marks a bearer as being more important than another one (the higher the number the more important the bearer); this matter when doing handovers, for instance, because, if you need to cut off some bearers (from lack of resources), you start by cutting off the ones with the smallest ARP values.

*** Still in the TS23.401 (page 38), you will find out that ARP is not a field, but a set of 3 (sub)fields:

PVI : Pre-emption vulnerability

PL : Priority Level

PCI : Pre-emption capability

*** Details of each of them on TS23.401 😛

— EPS Bearer TFT – as the TFT described above

If the MME verifies that everything is OK and the rest of the network is ready to create this new bearer, it replies to the above SGW’s message with a Create Bearer Response message, containing:

– Cause: set to 0 (Request accepted)

– Bearer context, having:

— EBI : set to 6 (the next EBI available) – ! still to verify with the TSs

— Cause: as above

— F-TEID – with the IP address of the S1-U eNB’s interface

— F-TEID – with the IP address of the S1-U SGW’s interface

And now we should be ready for traffic.

Whiiichhh, by the way, is encapsulated as GTPv1! Note to self: log a bug to 3GPP 😛

* first picture is the content of the Bearer Resource Command

* subsequent 2 pictures are from the Create Bearer Request

* last 2 pictures are from the Create Bearer Response

2 3 4 5 6

Iuhuuu

Iuhuuu

hurraaaaayyy

According to their official website: http://www.sfu420.com/?r=1

Six Feet Under is coming to Romania – 4 mai, in Baia Mare, Dacia Hall.

 

Everybody knows about this Quality of Service thinggie that helps admins to classify traffic and better allocate network and system resources to accommodate traffic needs and also to enforce the policies that exist for each user/groups of users – basically according to the amount of money they pay for this service 😛

In order to enforce a QoS on SAE entities, there are a few things to keep in mind:

A. PCRF – Policy Charging Rules Function device, which basically is a database that holds specific service QoS associations for each UE – this device is interrogated by the PGW in order to find out which QoS is applied on which traffic for each UE that requests a dedicated bearer

B. HSS – Home Subscriber Server, which has _nothing_ to do with QoS; this is a static database that holds information about the UE as is, and no information about any SLA of that UE with the provider

C. Only dedicated bearers hold a QoS level as part of their TFT association

D. The QoS on SAE has multiple variants, dividing the bearers into 2 groups:

GBR bearers (Guaranteed Bit Rate)

non-GBR bearers

E. The TFT (Traffic Flow Template – containing the filtering components for the traffic) that is associated with a bearer is not per flow, but per direction:

TFT-UL (TFT uplink)

TFT -DL (TFT downlink)

Also, the TFT can be:

bearer-level

SDF-level (service data flow level)

Now, we are interested in the GBR bearers. The GBR profile includes the following parameters:

1. QCI – QoS Class Identifier

Rules:

a. 1 QCI corresponds to 1 bearer only

b. 2 services having different QCI values can NOT be on the same bearer (TFT)

c. 2 services having the different QCI values can NOT have the same ARP (see below) value

d. QCI values must belong to [1..255]

2. ARP – Allocation & Retention Priority

Rules:

a. this value has NO influence on QoS

b. this value is set per eNB, following the PGW’s decision

c. it is established by PCRF according to a tuple of —activity type — subscription information — admission policies—

3. GBR – Guaranteed Bit Rate

4. MBR – Maximum Bit Rate

** There are also aggregated GBR bearers: AMBR (this is per APN) and UE-AMBR (the per-non-GBR, per UE rate) — [note to myself] to study more on this!

***Things to consider:

Thinking about the Mobility/Handover scenarios, keep in mind that, when a UE moves from one eNB to another, or from one MME to another, or from one SGW to another, the QoS is enforced on ALL the EPS components. This means that the QCI, ARP, GBR, MBR rates will all be verified on the resources of the destination (destination eNB, destination MME and so on). This means further on that, should at least one of the components not have enough resources to sustain all the QoS of a specific UE, some bearers will be dropped – this, again, is a decision of the SGW, taking into consideration, of course, the signaling came from the rest of the components.

[courtesy of my LTE guru colleagues]

As I was saying in a previous post, Bearers are structures that define a single QoS traffic between eNB – MME – SGW – PGW. They are created via GTP-C (control GTP) negotiation, and have effect on the actual traffic that flows between these entities (GTP-U – User plane). There 2 types of bearers: default bearers and dedicated bearers. While the default bearers are created by default during the Initial Attach procedure, simply stating that the UE is “logged in” the network (and usually no User plane traffic is permitted over these bearers), the dedicated bearers are created specifically when a particular type of application needs to send traffic over the network. If this happens, the network (here read PGW in correspondence with PCRF) looks at its QoS level. Should there be a TFT (associated to a dedicated bearer) already created for that application, the network simply uses that bearer to pass on those IP packets, otherwise it creates a new, dedicated, bearer, with a QoS specific to the needs of the application in question.

So… How is this “default bearer” created after all?

The most usual case is when the MME sends a Modify Bearer Request to the SGW. This message is a simple UDP packet, with destination port 2123, encapsulated as GTPv2. Its content looks like this:

– Flags: showing GTP version (2)

– Type of Message: “Modify Bearer Request”

– Length of Message: 30

– T-EID (Tunnel Endpoint Identifier) of the GTP-C on S11 (between MME and SGW)

– EPS Bearer ID

– F-TEID (Fully Qualified Tunnel Endpoint Identifier) which indicates the type of IP address (here it is IPv4), the type of interface where the bearer would take place (it is S1-U – S1 – User plane, the interface between the eNB served by the MME in question and the SGW in question)

** Why is this S1-U? Why this interface? Why a “U” interface? Because the purpose of the GTP-C is to negotiate the GTP-U part. Basically, via these GTP-C messages I am negotiating which are the GTP-U interfaces that will transfer the actual data. And, as MME is ONLY a GTP-C entity, it has the role of negotiating the bearers that will carry the traffic between the GTP-U entities, here eNB and SGW. So, the GTP-C passes through MME, while GTP-U does not. This is why I can see on the GTP-C message sent from MME to SGW the TEID of a S1 interface, rather than a S11 interface.

– F-TEID IPv4 – this is the IP address of the eNB, in this case 40.0.0.3

** This F-TEID IPv4 is the actual IP address that eNB will use in order to send data-plane packets flowing between UE and PDN. As the path of the GTP-U is between UE – eNB – SGW – PGW – PDN ( the MME only appears in the GTP-C flow), the F-TEID IPv4 address here should have layer 3 connectivity with the SGW IP address. I had a rough time today trying to understand why on earth my GTP-U traffic disappeared, while I was having the eNB and SGW IP addresses on two different subnets and no router to route packets from one subnet to another – smarty, I know 😛

The Modify Bearer Request packet looks something like this:

Screen-shot-2010-02-15-at-10.28.51-PM

If the MME has been a good kid (and the UE also), the SGW acknowledges its request and responds with a Modify Bearer Response packet having as Cause : Request accepted. The fields of this packet are the following:

– Flags – indicating the GTPv2 and some other stuff

– Cause – has the IE (Information Element) type, which is 2 here, Cause being Request Accepted and the ID of the Cause is 0 (it should be different than 0 if the request were not accepted)

– Bearer Context – this indicates that the SGW reserved resources for a new context (default one) and instructs the eNB and the PGW to do the same; this field contains the

– – –  EPS Bearer ID : 5

– – – Cause subfield : indicates “Request accepted”

– – – F-TEID: type of IPv4, the interface is S1-U (S1 – User plane between eNB and SGW) and the F-TEID IP is the IP address of the SGW (40.0.0.2)

Basically this message confirms the creation of the Default Bearer, the reservation of the network resources for the traffic flowing over this bearer (if any). The user is officially logged in the network and has the first, most simple and non-priviledged session with the PDN.

The Modify Bearer Response packet looks something like this:

Screen-shot-2010-02-15-at-10.37.12-PM

Screen-shot-2010-02-15-at-10.37.43-PM

LTE buzz

Posted: February 9, 2010 in technical
Tags: , , ,

The ALU guys were so nice to help us stay in touch with the latest LTE news worldwide.

Today I’ve got an e-mail with a cool link to LTE Buzz , a funky widget that lists the latest feeds related to LTE.

lte_buzz