HP 635n Practical IPsec Deployment for Printing and Imaging Devices - Page 25

IPsec Basics: IPsec Policy - Packet Matching

Page 25 highlights

IPsec Basics: IPsec Policy - Packet Matching When an IP packet is being sent down to the Ethernet layer, the IPsec component steps in and intercepts the packet. IPsec will need to inspect the various fields of the packet to determine whether the packet matches any of the "rules" of the IPsec Policy. In many implementations of IPsec, the packet matching parameters are combined together and called an IP Filter or a Selector. An IP Filter / Selector answers the following question: of the IP packets being sent down the stack, which IP packets do I care about - which ones do I "filter" out to give special consideration? An IP filter operates off of several parameters. Two of the most obvious ones are the Source IP Address and Destination IP Address. We learned from the fossil analogy that these addresses keep track of the original source and final destination of the packet, unlike the Ethernet addresses (NOTE: This whitepaper does not discuss IPsec Network Address Translation (NAT) or NAT traversal for the Intranet). The IP header also has a field called Protocol Type - which describes the type of data it is carrying. This field could be TCP, UDP, ICMP, or many other values. This is another field that will be important for IP Filters. Within the TCP and UDP headers, there are fields called "port numbers". Some of these port numbers are dynamic and some represent well-known protocols. For instance, TCP Port 80 is assigned to HTTP, the common protocol used when surfing the web. These fields are also important for IP filters. (NOTE: While ICMPv4 and ICMPv6 message types and codes can also be protected via IPsec, this whitepaper will focus on applications using UDP and TCP). Let's look at an example IPsec policy focusing primarily on Packet Matching. The IPsec Policy is in the form of a table. Each row in the table is called a rule. IPsec looks at a given IP packet and then extracts the information from that packet. This information is then compared to the information present in the IPsec Policy. The IPsec Policy is processed from Rule 1 to the last rule or the default. If there is a match, then no more rules are processed. Refer to Table 1 - Basic IPsec Policy. Rule # 1 From IP My IP 2 My IP 3 DEFAULT My IP ANY To IP Printer IP Protocol TCP From Port To Port Any 443 Printer IP TCP Printer IP ANY TCP ANY Any Any ANY 9100 80 ANY Table 1 - Basic IPsec Policy Action Allow without IPsec Protection Require IPsec Protection Drop Packet Allow without IPsec protection Refer back to Figure 22. IPsec is intercepting a packet coming from the IP layer (being transmitted). IPsec does the following for each rule starting with Rule 1: • Does the Source IP address from the packet match the "From IP" column in the IPsec Policy? • Does the Destination IP address from the packet match the "To IP" column in the IPsec Policy? • Does the IP Protocol from the packet match the "Protocol" column in the IPsec Policy? • Does the Transport Source Port from the packet match the "From Port" column in the IPsec Policy? • Does the Transport Destination Port from the packet match the "To Port" column in the IPsec Policy? Let's work through an example. Let's say the packet that IPsec intercepted has the following values: 25

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193

25
IPsec Basics: IPsec Policy – Packet Matching
When an IP packet is being sent down to the Ethernet layer, the IPsec component steps in and
intercepts the packet.
IPsec will need to inspect the various fields of the packet to determine whether
the packet matches any of the “rules” of the IPsec Policy.
In many implementations of IPsec, the
packet matching parameters are combined together and called an IP Filter or a Selector.
An IP Filter
/ Selector answers the following question: of the IP packets being sent down the stack, which IP
packets do I care about – which ones do I “filter” out to give special consideration?
An IP filter operates off of several parameters.
Two of the most obvious ones are the Source IP
Address and Destination IP Address.
We learned from the fossil analogy that these addresses keep
track of the original source and final destination of the packet, unlike the Ethernet addresses
(NOTE:
This whitepaper does not discuss IPsec Network Address Translation (NAT) or NAT traversal for the
Intranet)
.
The IP header also has a field called Protocol Type – which describes the type of data it is
carrying.
This field could be TCP, UDP, ICMP, or many other values.
This is another field that will be
important for IP Filters. Within the TCP and UDP headers, there are fields called “port numbers”.
Some of these port numbers are dynamic and some represent well-known protocols.
For instance,
TCP Port 80 is assigned to HTTP, the common protocol used when surfing the web.
These fields are
also important for IP filters.
(NOTE: While ICMPv4 and ICMPv6 message types and codes can also
be protected via IPsec, this whitepaper will focus on applications using UDP and TCP)
.
Let’s look at an example IPsec policy focusing primarily on Packet Matching. The IPsec Policy is in the
form of a table.
Each row in the table is called a rule.
IPsec looks at a given IP packet and then
extracts the information from that packet.
This information is then compared to the information
present in the IPsec Policy.
The IPsec Policy is processed from Rule 1 to the last rule or the default.
If
there is a match, then no more rules are processed.
Refer to Table 1 – Basic IPsec Policy.
Rule #
From IP
To IP
Protocol
From Port
To Port
Action
1
My IP
Printer IP
TCP
Any
443
Allow
without
IPsec
Protection
2
My IP
Printer IP
TCP
Any
9100
Require
IPsec
Protection
3
My IP
Printer IP
TCP
Any
80
Drop Packet
DEFAULT
ANY
ANY
ANY
ANY
ANY
Allow
without
IPsec
protection
Table 1 – Basic IPsec Policy
Refer back to Figure 22.
IPsec is intercepting a packet coming from the IP layer (being transmitted).
IPsec does the following for each rule starting with Rule 1:
Does the Source IP address from the packet match the “From IP” column in the IPsec Policy?
Does the Destination IP address from the packet match the “To IP” column in the IPsec Policy?
Does the IP Protocol from the packet match the “Protocol” column in the IPsec Policy?
Does the Transport Source Port from the packet match the “From Port” column in the IPsec
Policy?
Does the Transport Destination Port from the packet match the “To Port” column in the IPsec
Policy?
Let’s work through an example. Let’s say the packet that IPsec intercepted has the following values: