Archive for January, 2010

9
Jan

to Summit or not to Summit

   Posted by: cristina_crow    in technical

I say definitely to Summit. A very peculiar device, that amazed me instantly.

It is one of the products of Extreme Networks, don’t know how big of a company, but I got to love their solution. Even one of the smallest and lowest performance solution they have (Summit48si)  distinguished by its loads of features, performance, ease of configuration and, above all, STABILITY, something I haven’t found at the mighty Cisco solution that everybody loves.

A while back I needed to do something very specific: I wanted to separate traffic coming from two networks on trunks. My device should have reunited all this traffic and forward it to a different machine that would NAT it forward on to my servers. Each done by any device easily. But – what I wanted more was at the authentication level. I wanted to do 802.1x authentication on trunks and forward the authenticated traffic to a secondary device that would do EAPoverUDP for some of the traffic and WebAuth for the rest of the traffic, all based on the ACLs configured on a separate Radius (ACS) server. Now, I won’t get into details about the EoU, WebAuth, nor ACS configuration, but rather describe what I have managed to do with Summit.

First of all, unlike other devices, this one allows the premises of my topology: it lets me configure 802.1x on a trunk port – which I wasn’t able to obtain from Cisco after long hours of pain and swearing. So, traffic is coming from my supplicants, on 3 ports of this Summit device, let’s say 1,2 and 3. Ports 1 and 2 carry only 802.1x authenticated traffic, while port 3 is a combination of 802.1x, EoU and WebAuth. So, I have defined 4 vlans: 1,2,3 and 4. As part of my traffic is only authenticated with 802.1x, I left the first 2 ports authenticated in 802.1x on vlan 1, and assigned the next port (3) on all of the other 3 vlans: 2,3 and 4. This is this the access portion of the topology.

The second part, I have to switch all this traffic through another device, that deals with EoU and WebAuth, so I have defined 5 “exit” ports: 1 for the 802.1x authenticated traffic that wouldn’t need any other authentication (this traffic I trust to be secure only as part of the Summit authentication), 2 ports for the mixed-authentication traffic (this traffic I have authenticated via 802.1x in Summit, and I trust it), and 2 more ports for the traffic I want to further re-authenticate: 1 for the mixed traffic that has 802.1x and EoU and that I intend to authenticate via EoU and 1 port for the mixed 802.1x and WebAuth traffic that I intend to authenticate via WebAuth further on. The scenario would look something like this:

—where:

-’vlan 1′ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via EoU here

- ‘vlan 2′ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via WebAuth here

Some of the traffic is only authenticated via EoU and WebAuth, so I have to let it pass through Summit without asking it for credentials.

From these 2 vlans, the traffic passes back into the internal network where the servers reside – this is of no further interest in this case. Still, I had to create 2 vlans, because of the default gateways that I need to assigned to my supplicants. One would be the layer 3 address of vlan 1 and the second would be the layer 3 address of vlan 2.

The cool part of this entire topology is how to fragment the traffic in Summit, in order to make sure that each type of authentication takes place where it is supposed to.

Of course, the ports belonging to vlans 1 and 2 are “access mode” untagged ports. Ports from 11 to 15 on the Summit device are also untagged ports, while ports 1 and 2 are untagged in a specific 802.1x vlan (let’s say 111), ports 3, 4 and 5 are double-tagged on a separate vlan (as they have mixed traffic that is to be authenticated on EoU and WebAuth separately further on, let’s say 117 for traffic that is to be forwarded to EoU authentication ports and 118 for traffic that is to be forwarded to WebAuth authentication ports) and untagged on vlan 113 – also an 802.1x enabled access vlan (as they also carry 802.1x information). Now, all this funky division is necessary for the netlogin information (as Summit calls the 802.1x authentication).

And the actual config looks like this:

# Config information for VLAN v111.
configure vlan “v111″ tag 111
configure vlan “v111″ protocol “ANY”
configure vlan “v111″ qosprofile “QP1″
# No IP address is configured for VLAN v111.
configure vlan “v111″ add port 1 untagged
configure vlan “v111″ add port 2 untagged
configure vlan “v111″ add port 11 untagged
# Config information for VLAN v113.
configure vlan “v113″ tag 113
configure vlan “v113″ add port 3 untagged
configure vlan “v113″ add port 4 untagged
configure vlan “v113″ add port 5 untagged
configure vlan “v113″ add port 12 untagged
configure vlan “v113″ add port 13 untagged
# Config information for VLAN v117.
configure vlan “v117″ tag 117
configure vlan “v117″ protocol “ANY”
configure vlan “v117″ qosprofile “QP1″
# No IP address is configured for VLAN v117.
configure vlan “v117″ add port 14 untagged
configure vlan “v117″ add port 3 tagged
configure vlan “v117″ add port 4 tagged
configure vlan “v117″ add port 5 tagged
#
# Config information for VLAN v118.
configure vlan “v118″ tag 118
configure vlan “v118″ protocol “ANY”
configure vlan “v118″ qosprofile “QP1″
# No IP address is configured for VLAN v118.
configure vlan “v118″ add port 15 untagged
configure vlan “v118″ add port 3 tagged
configure vlan “v118″ add port 4 tagged
configure vlan “v118″ add port 5 tagged
The netlogin command has been issued for ports 1,2,3,4,5, but only on vlans 111 and 113.
# Network Login Configuration
enable netlogin port 1 vlan v111
enable netlogin port 2 vlan v111
enable netlogin port 3 vlan v113
enable netlogin port 4 vlan v113
enable netlogin port 5 vlan v113
configure netlogin base-url “network-access.net”
configure netlogin redirect-page “http://www.extremenetworks.com”
disable netlogin Session-Refresh  3
enable netlogin logout-privilege
disable netlogin web-based
enable netlogin dot1x
The show netlogin command shows, at any moment, the status of the port (per un/tagged vlan), looking something like this:
> sh netlogin ports 1 vlan v111
Port: 1 Vlan: v111
Port State:     Not Authenticated
Temp IP:        Unknown
DHCP:           Not Enabled

MAC                IP address      Auth   Type      ReAuth-Timer User
——————————————————————
When in non-authenticated state. When actually authenticating a supplicant, the command displays the MAC address, IP (if the case), auth type and name of the user.
And, to actually be able to _authenticate_ users, I have to define  a Radius server where to connect:
# Radius configuration
#
enable radius
configure radius primary shared-secret encrypted “ABC”
configure radius timeout 30
configure radius primary server 1.2.3.4 1645 client-ip 1.2.3.5
configure radius primary server 1.2.3.5 timeout 30
disable radius-accounting
The “1.2.3.5″ IP is the Summit IP address, that I have assigned on a separate vlan. Of course, ACS should have defined this IP as a client with a password of “ABC” – encrypted form and profiles for my users.
But about ACS in the next episode :P

Tags: , , , , , ,

5 Comments
6
Jan

manual …keying

   Posted by: cristina_crow    in technical

Everybody loves IPsec. It does a lot of cool stuff protecting our traffic from one side to another, it is fairly easy to understand the general concept, but quite difficult to actually implement in real-life, mostly because a lot of vendors have their own idea of usability and each one has its own idea of actually implementing those numerous standards. Some of them decide to implement drafts (see Cisco, see CheckPoint) and some of them implement their own “drafts” – which makes things even more interesting.

Some other vendors decide to overcome the entire negotiation fuss and use predefined keys for the IPsec traffic, bypassing all the IKE negotiation and using manual keying. Here we have Cisco, Juniper, Sonicwall or our lovely Linux solutions.

In order to manually configure IPsec, the admin alters the SAD (Security Association Database) and SPD(Security Policy Database) databases of the device/kernel. The SAD contains specific traffic transformations, like the encryption/authentication algorithms, while the SPD indicates the traffic selectors/proxy-ids for the traffic that is to be transformed by the stuff described in SAD and indexed by an SPI.

An SAD entry would include:

  • Dest IP address
  • Ipsec proto (SA or ESP)
  • SPI (cookie)
  • Sequnce counter
  • Seq O/F flag
  • anti-replay window info
  • AH type and info
  • ESP type and info
  • Lifetime info
  • tunnel/transport mode flags
  • PATH MTU info

An SPD entry would contain:

  • pointer to active SAs
  • Selector fields

***Let’s take a simple site-to-site tunnel mode case, where the security gateways are 2001::1 (local gateway) and 2001::2 (remote gateway) and the subnet behind the local gateway is 2002::/112 and the one behind the remote gateway is 2003::/112. As you can imagine, I want to encrypt traffic between 2002::/112 and 2003::/112 with aes-cbc, let’s say and authenticate it with hmac-md5.

In order to configure manual keying on linux, we need to have:

- xfrm modules in ze kernel:

xfrm4_mode_transport     1792  0

xfrm6_mode_transport     1792  0
xfrm6_mode_tunnel       2208  0
xfrm4_mode_tunnel       2304  0
xfrm_user              17856  0
xfrm4_tunnel            2304  0
tunnel4                 3016  1 xfrm4_tunnel
ipv6                  235396  33 ah6,esp6,xfrm6_mode_tunnel

- and a small script that instructs the kernel on how to populate those two databases:

ip xfrm state add src 2001:0::2 dst 2001:0::1 proto esp spi 0×1000 enc “cbc(aes)”  0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414  auth “hmac(md5)” 0x012345abd9abcdeff1e0d3c2b5a4909a

ip xfrm state add src 2001:0::1 dst 2001:0::2 proto esp spi 0×2000 enc “cbc(aes)” 0xf4f71123452c1b07bce4e63b4c31541d12345678abcdef12  auth “hmac(md5)” 0x912345abd9abcdeff1e0d3c2b5a49080

ip xfrm policy add dir in src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

ip xfrm policy add dir out src 2002::/112 dst 2003::/112 tmpl src 2001:0::1 dst 2001:0::2 proto esp mode tunnel

ip xfrm policy add dir fwd src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

—– Now we should be able to see that:
# ip xfrm state
src 2001::2 dst 2001::1
proto esp spi 0×00001000 reqid 0 mode transport
replay-window 0
auth hmac(md5) 0x012345abd9abcdeff1e0d3c2b5a4909a
enc cbc(aes) 0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414
sel src ::/0 dst ::/0
src 2001::1 dst 2001::2
proto esp spi 0×00002000 reqid 0 mode transport
replay-window 0
auth hmac(md5) 0x912345abd9abcdeff1e0d3c2b5a49080
enc cbc(aes) 0xf4f71123452c1b07bce4e63b4c31541d12345678abcdef12
sel src ::/0 dst ::/0
—–and
# ip xfrm policy
src 2003::/112 dst 2002::/112
dir in priority 0
tmpl src 2001::2 dst 2001::1
proto esp reqid 0 mode tunnel
src 2002::/112 dst 2003::/112
dir out priority 0
tmpl src 2001::1 dst 2001::2
proto esp reqid 0 mode tunnel
src 2003::/112 dst 2002::/112
dir fwd priority 0
tmpl src 2001::2 dst 2001::1
proto esp reqid 0 mode tunnel
—–to delete the rules simply run:
ip xfrm state flush
ip xfrm policy flush

When trying to do interop with…NetScreen, let’s say, bare in mind that this device only permits one key per connection, not as linux xfrm, which lets you select a key per direction. A NetScreen config would look something like this…
I have defined a tunnel.1 interface in the Untrust zone of the device and configured the ‘vpn’ objects like it follows (as you can see, no need for any ‘ike’ objects, as there is no IKE going on in there):
set vpn “IPv6_manual” id 0x1c1e manual 2000 2000 gateway 2001::10 outgoing-interface “ethernet2/2″  local-address “2001::1″  ah md5 key 0101010101010101,0101010101010101
—this populates the SAD of the NetScreen device, while this:

set policy id 7155 name “IPv6_TU_man” from “Trust” to “Untrust”  ”IPv6_Man2″ “IPv6_Man1″ “ANY” tunnel vpn “IPv6_manual”
set policy id 7155
exit
set policy id 15155 name “IPv6_UT_man” from “Untrust” to “Trust”  ”IPv6_Man1″ “IPv6_Man2″ “ANY” tunnel vpn “IPv6_manual”
set policy id 15155
exit
—populates the SPD of the device; of course, the IPv6_Man1 and IPv6_Man2 are names of the IPv6 interfaces (public and private, respectively)
And, as the keys are already into the device’s kernel, I can simply list them with a fairly nice command:
-> get sa active
00001c1e<        2001::10  500  ah:null/md5  00002000   n/a   n/a M/- 15155 0
00001c1e>        2001::10  500  ah:null/md5  00002000   n/a   n/a M/-  7155 0
Voila!

Tags: , , , , , ,

2 Comments
4
Jan

my first eGTP test

   Posted by: cristina_crow    in technical

Today I have created my first eGTP scenario, trying to analyze the Wireshark capture and better understand this protocol…

eGTP, or GTPv2 is one of the ongoing and work in progress 3GPP standards, following the GTPv1 of UMTS, eGTP is used on the SAE architecture, GTP-c (GTP Control-Plane) between the two components of the EPS (Evolved Packet System): MME (Mobility Management Entity) and SGW (Serving Gateway) and between SGW and PGW (PDN Gateway) and GTP-u(GTP User-Plane) between eNodeB and SGW for the user traffic.

Basically, when the phone/UE (User Equipment) is turned on, it looks for a radio network. When it finds one, it signals its location and identity and tries to contact it’s home network – procedure called initial attach. During this procedure, the UE is given a permanent IP address by the PGW (PDN – Packet Data Network Gateway) – this being one of the purposes of this attach procedure. As a consequence, a (default) bearer (UMTS context) is created, a basic connection between the UE and the PGW, mainly to identify the UE in the PGW and keep track of its existence while it is connected to the network. This procedure is basically the initial registration to the network and the messages exchanged here are part of the so-called control-plane traffic.

The complete signaling scheme is triggered by the UE sending an AttachRequest to its closest eNodeB device, this forwards the request to its MME (to one of its MMEs, if there are more), then MME talks to SGW (after allocating an EPS bearer ID for the default bearer associated with the UE) and the SGW talks to PGW, in order to create a session for our user. The complete flow is presented below.

Still, what is of interest to eGTP, the flow between MME and SGW consists of only 2 messages: CreateSessionRequest and CreateSessionResponse (in case the bearer is modified, also ModifyBearerRequest and ModifyBearerResponse).

The CreateSessionRequest contains:

- identification information of the UE (IMSI, MSISDN, MEI – Mobile Equipment Identity, ULI – User Location Information)

- information regarding the radio access: the access can be E-UTRAN (where we have an eNodeB device) or other 3GPP and non-3GPP RANs

- information about the destination network /serving network (MCC – Mobile Country Code and MNC – Mobile Network Code)

- information about the path of the tunnel – where the user is to be registered; as the user is registered on the PGW, and this message (CreateSessionRequest) is sent by the MME, the next logical hop is the SGW; therefore there are 2 Fully Qualified Tunnel Endpoint Identifiers:

– one for the S11 interface (the one between MME and SGW)

– one for the S5/S8 interface (the one between SGW and PGW)

these two headers contain a field called F-TEID IPv4 (or IPv6) having as values the IP address of the next logical interface (SGW’s S11, respectively PGW’s S5/S8 interface)

- type of the final gateway (registration point): either IPv4 or IPv6

- information about the type of transaction in place, like: type of network selection, PDN address allocation (0.0.0.0 in this message on S11) and an Indication header used for future signaling in case a Handover takes place, for instance

- the APN (Access Point Name) – DNS name, APN restrictions, AMBR (Aggregate Maximum Bit Rate) – used in QoS (I’ll study this one later on), Bearer information (ID, QoS…) and a Restart Counter

Following up this message, the SGW also creates an entry for the default bearer of that UE and sends a CreateBearerRequest message to the PGW.

The CreateSessionResponse in the next chapter :P

***I have noticed that, in order to completely understand the entire flow of messages is better to follow-up a type of message from its starting point (let’s say, the UE or eNodeB triggering the flow) up until the PGW device. The message above has been caught on the S11 interface, between the MME and the SGW, but

Tags: , , , , , , , ,

5 Comments
Back to top
Next Entries