Need an ISO8583 Application Switch for card transactions?
What is ISO8583: ISO 8583 Financial transaction card originated messages — Interchange message specifications is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. The first two digits in the ISO8583 message aren't important. However, the next four are what tell us about the type of message we are processing. For more information: http://en.wikipedia.org/wiki/ISO_8583 Using the rule below as a template you should be able to dynamically switch any ISO8583 message to the desired server. See if this helps: when CLIENT_ACCEPTED{ TCP::collect } This section collects the first 6 bytes and then uses 'switch' to find a match. It allows to you decide where to send a request based on its message type. You could also use this to simply log without performing a pool selection. when CLIENT_DATA { log local0. "in CLIENT_DATA" set clientData [TCP::payload 6] log local0. "Client Data raw: $clientData" switch -glob $clientData{ "??0800"{ pool pool_EchoTestMessage log local0. "This is a Network Management Message." } "??0810"{pool pool_ForClientAuthorizations} } TCP::release } when SERVER_CONNECTED { TCP::collect } This section allows you to perform an action base on the message type of the response from the server. You could log the message type or even manipulate it before sending it out. when SERVER_DATA{ set serverData [TCP::payload 6] log local0. "Response Data raw: $serverData" switch -glob $serverData{ "??0810"{ log local0. "This is a Network Management Message." } "??0820"{log local0. "This is type XXX" } } TCP::release }ISO8583 payload interpreter/switch
The previous verion of ISO8583 switch only processed the MTI (Message Type Identifier). This version goes far beyond and dives into the bitmap and payload. What does it do: 1) It reads and interprets the ISO8583 bitmap 2) It calculate the offset based on the fields present in the message With these two points we now have access to the message payload allowing one to pick out client identifier or location information (bits 41 & 42) or anything else you want access to. This information can be used for simple logging, routing or anything else you might be after. The following rule grabs field 63. Being a variable length field, it must retrieve the field length from within the payload before being able to locate the desired field data. when RULE_INIT { Build list of Bitmap Attribute Lengths 'var' represents a variable length field set static::bmAttrLengths [list 64 LL 6 12 12 12 10 8 8 8 6 6 4 4 4 4 4 4 3 3 3 3 3 3 2 2 1 8 8 8 8 LL LL LL LL LLL 12 6 2 3 8 15 40 LL LL LLL LLL LLL 3 3 3 64 16 LLL LLL LLL 12 12 12 LLL LLL LLL LLL 64] } when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { set clientData [TCP::payload] log local0. "Client Data raw: $clientData" Collect the bitmap from the payload - it follows the MTI. binary scan [binary format H* [string range $clientData 6 21]] B* data Start the offset at 22 for MTA & BitMap padding set offset 22 set i 0 while { $i < [string length $data]} { if {[string index $data $i] == 1} { set attr [lindex $static::bmAttrLengths $i] if { $attr == "LL" } { This is a variable length field. The next 2 values in the string tell us how long the field is. set beginData [expr { $offset + 2 }] set endData [expr { $beginData + [scan [string range $clientData $offset [expr { $offset + 1 }]] %d ]}] log local0. "Value for the field length is: [string range $clientData $offset [expr { $offset + 1 }]]" log local0. "Value for the Field is: [string range $clientData $beginData $endData]" } elseif { $attr == "LLL" } { This is a variable length field. The next 3 values in the string tell us how long the field is. set beginData [expr { $offset + 3 }] set endData [expr { $beginData + [scan [string range $clientData $offset [expr { $offset + 2 }]] %d ]}] log local0. "Value for the field length is: [string range $clientData $offset [expr { $offset + 2 }]]" log local0. "Value for the Field is: [string range $clientData $beginData $endData]" } else { We got a 1 in the bitmap - increment the offset. incr offset [lindex $static::bmAttrLengths $i] } } incr i } TCP::release } Tester feedback welcom and encourage - I only have access to an ISO8583 emulator written in python.
Creating a proper RADIUS Accounting-Response packet in iRules
Creating a proper RADIUS Accounting-Response packet in iRules If you do a lot of work with RADIUS messages being sent to your BIGIP so that you can get some information from another network node in the system, you are going to need to respond back to that node in a correct and proper way, so that you don’t mess it up, or otherwise fill up its error log with ‘improper response’ messages. I was working on just that kind of iRule, and got it working. Here’s the code: 1: 2: RADIUS Acct-Resp packet 3: 4: input variables: 5: $rId -> RADIUS Request ID field 6: $rAuth -> RADIUS Request Authorization field 7: $static::SHARED_SECRET -> RADIUS Shared secret of the 2 nodes. 8: 9: UDP::drop ; kill the incoming packet, don’t need it. 10: set RADcode 5 ; RADIUS Accounting-Response Type code. 11: set md5hash [ format "05%02x00%02x" $rId 20 ] 12: set md5hash $md5hash$rAuth$static::SHARED_SECRET 13: set hash [ binary format H* $md5hash ] 14: set respAuth [md5 $hash] 15: set payldhdr [ binary format ccS $RADcode $rId 20 ] 16: set payload $payldhdr$respAuth 17: UDP::respond $payload So the RADIUS Accounting-Response packet has, at a minimum, four fields: RADIUS Type code(1 byte), ID number(1 byte), Packet Length(2 byte Integer), and the Authenticator(16 bytes). Getting the response authenticator correct is really the only tricky part. Line 5: The RADIUS Request ID field comes from the incoming packet. You can retrieve this value previously in the iRule using a line of code like this: set rId [RADIUS::id]. Of course, this value can also be pulled out at the same time some other important fields are decoded using the sample code for line 6 below. Line 6: The RADIUS Request Authorization field in the incoming packet is an MD5 hash of most if the incoming packet. To get this value, you will need to do a binary scan of the UDP packet: set payload [UDP::payload] binary scan $payload ccSH32a* rType rId rLen rAuth rPkt In this example, we also pull out the Type Code (rType) and the packet ID (rId), the length of the overall packet, the Authorization field that we are looking for, and the rest of the packet, which should be all the AVP fields. Line 9: We don’t need (and usually don’t want) the RADIUS Request packet from going on from the BIGIP, so we just drop the packet to prevent this. Line 10: 0x05 is the RADIUS Type Code for an Account-Response packet. Line 11: Here’s where we start working on our response authenticator. We are going to setup a hexstring (which is hex characters displayed as a string; IE> “05140016” is four bytes 0x05, 0x14, 0x00, 0x16), pack all of our values into it, convert it to real binary hex, do the MD5 hash on the result, and use the MD5 checksum result in the response packet. This line sets Type Code, id, and Length (hard coded to 20 bytes). Line 12: Using the hexstring from the last line, it adds the Original request Authenticator, and the shared secret (which should already be in hexstring format) to it. We now have our complete hexstring that needs to be run through the MD5 checksum function. Line 13: This line simply converts the hexstring to a binary hex value. Line 14: We get our valid Authenticator for the response. Line 15: Now we create the actual response packet. This line sets the first three fields: Type Code, id, and Length. Line 16: We add the header and the response Authenticator and we have our RADIUS Accounting-Response packet. Line 17: Send the response back. The RADIUS Accounting-Response protocol is documented in RFC-2866, Section 4.2.
newcomer to iso 8583
Hi, we acquired our first bigip this summer and one of our projects has to deal with a customized version of iso 8583. Honestly we don't know where to start to implement parsing of this protocol. Are there implementations or resources we can start with, or any information on this topic you can point us to ? Thank you for helping a beginner ! Alain
ISO 8583 Field Formatting
Hi guys, I am new to ISO 8583. I want to know how to package my response to a Balance enquiry that in addition to the balance value (Field 54), should also show the Earning and Redemption history (if any) I want to package the earning and redemption history in Fields 62 and 63. I want to put the last 5 Earnings and last 5 Redemptions. This fields are designated as ans..999. I am developing this soultion in C (Visual Studio 2012). Any ideas on how i will cram 5 distinct values in either field. I will really appreciate it. Thanks, O. MosetiLeast Sessions balancing and Server restart
Hi, I am running F5 BigIp with 11.2.00 HF2. I am playing with the Diameter iApp and Least Sessions balancing policy. I have 3 servers in my setup and the following scenario: 1. 3 servers running and traffic balancer among these servers 2. 1 of the servers goes down and the new traffic is re-balanced to other servers (universal persistence in place) 3. After a while the server comes back, and Diameter monitor sets it up as the 'Available" one. What I am expecting in this situation is, that new sessions will be routed to this new server, which was restored, but this is not a case. I check the Round Robin and it in general, it was quite fine. I saw some time ago the information, that actually due to different bugs, for Diameter only teh Round Robin policy is really working. Is this still a case? Did you have similar experiences with F5 and Diameter traffic balancing? Rgds, DeeN
What to tell web developers
I have not seen a group to post this subject so I will start here: I am being give an opportunity to tell our web developers how they must write code to work in a wide area load balanced environment. We have had issues in the past where the "create user" web page would get load balanced to two different websites during the creation process so it would have the same user in two different active directory controllers. When AD tried to replicate, it failed and shut down services from AD. Ugly situation, but ... what else have you seen that might be helpful in telling them what not to do in their code? I have started with my sales guys, and Professional services - they say something to the effect "we just make it work through the F5", but given an opportunity such as this, I could prevent alot of issues (and that is what MGMT is expecting to occur) Thank You,How to decode the five different data types in a RADIUS packet
How to decode the five different data types in a RADIUS packet When a handset device on a cellular carrier turns on, usually a RADIUS packet is generated and sent out to a number of different network nodes to let them know that the handset device is on and about to access services of the wireless network. In some of those networks, F5 BIGIP devices also receive this RADIUS packet so that they too can get ready to handle network traffic from the handset device. Some times the BIGIP will query some sort of AAA or Policy servers to see if the handset device is allowed to connect to nodes beyond the BIGIP, and needs some of the information contained in the RADIUS packet in order to do the query. Here’s how to pull that information out within iRules. RADIUS packets have five official data types: Integer, Text, String, IPAddress, and Time. These are defined in the RADIUS standards (RFC-2865, RFC-2866, among others). “String” can be something of a misnomer, as it can contain binary data. “Text” is used for textual, printable, strings (I.E. UTF-8 encoded characters). Of these five types, only Text can be used without modification or checks. Here’s how to decode the other four: Integer -- One would think that you could use Integer types without modification, but there is one subtle gotcha. RADIUS integers are “unsigned”, meaning they are always positive. iRules integers are signed – the left-most bit is used as a flag to denote positive and negative numbers. If the left-most bit is set, then the number is negative. So in some cases, the numbers coming from RADIUS may show up as negative, rather than positive, numbers. You just need to make sure this left-most bit is unset: set acctAuthen [RADIUS::avp 45 "integer"] set acctAuthen [expr { $acctAuthen && 0xff }] if { $static::DEBUG eq 1 && $acctAuthen != "" } { puts "Acct-Authentic: $acctAuthen" } String -- Since iRules can handle non-UTF-8 bytes in its string type, there is no issue using what you get from the RADIUS packet without modification. The problem comes if you want to print out or otherwise log the contents of the String when its holding binary data. This can be done using a simple binary scan command: set acctSessId [RADIUS::avp 44 "string"] binary scan $acctSessId H* acctSessId if { $static::DEBUG eq 1 && $acctSessId != "" } { puts "Acct-Session-Id: $acctSessId" } In /var/log/tmm: … local/bigipfw notice Acct-Session-Id: ff082000 IPAddress -- Or “address” as its referenced in the spec. This is almost always an IPv4 address. When you retrieve this avp, you get a four-byte string, with the four octets of an IPv4 address. It’s pretty simple to decode: set a1 [RADIUS::avp 8 "ipaddr"] ; network byte order binary scan $a1 cccc a b c d set a [expr { $a & 0xff }] ; make unsigned values set b [expr { $b & 0xff }] set c [expr { $c & 0xff }] set d [expr { $c & 0xff }] set frmdIPAddr "$a.$b.$c.$d" if { $static::DEBUG eq 1 & $frmdIPAddr != "" } { puts "Framed-IP-Address: $frmdIPAddr" } Time -- These values are stored as a four-byte “epoch” value (this is, the number of seconds since July 1, 1970… which I believe was the next closest start of the month at the time the programmer who wrote the procedure, wrote it). Give that iRules is derived from the TCL programming language, we are lucky in that TCL has built in functions to manipulate this value and print out a date/time format that we can use: set eventTimestamp [RADIUS::avp 55 "integer"] set timest [clock format $eventTimestamp -format {%a %b %d %Y %H:%M:%S}] if { $static::DEBUG eq 1 && $timest != "" } { puts "Event-Timestamp: $timest" } More information about the RADIUS:: iRules commands can be found .
IPv6
As many of you are aware, IPv6 module has been available on BIG-IP LTM since 9/2004 when v9 was first released. With OMB-set deadline looming just about a year away to implement IPv6 for public sites, we are seeing more customers inquiring about our IPv6 capability. With v9 code, IPv6 must be purchased as an optional module (enabled with a license key). However, if your hardware is compatible with v10, then IPv6 module will come included in the v10 upgrade. Also, we have submitted BIG-IP for USGv6 certification ahead of our own schedule. http://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php Look us up at the World IPv6 Day on June 8! John