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

Printing with an IPsec Policy

Page 24 highlights

Figure 22 - Printing with an IPsec Policy Starting at the top and working down, we can see the how vital a role the IPsec policy plays in determining which packets are protected and which are not. An IPsec policy can specify that IP packets don't need IPsec and can be transmitted without IPsec protection. In addition, the IPsec policy can specify that IP packets should be discarded as well as IP packets that must be transmitted with IPsec protection. Another important point to note in the figure is that the IP packet that received IPsec protection has its content encrypted. This encryption provides confidentiality and is shown by the yellow color and the brackets around TCP and Print Data. Should this IP packet be captured by Wireshark, the contents in yellow are unreadable and appear like random data. In fact, the Wireshark capture won't be able to tell if this is a TCP packet or what protocols IPsec is carrying. All Wireshark will be able to tell is that it is an IPsec packet with the data protected via IPsec confidentiality (i.e., encryption). NOTE: It is possible to run IPsec in various modes that may not provide for confidentiality. This whitepaper will only be considering IPsec deployment where confidentiality and authentication are a requirement. In addition, IPsec can be configured for Tunnel Mode, where the entire IP packet (IP header and payload) is part of the protected IPsec payload, which is often done for VPNs. For the purposes of Intranet security, this mode is unnecessary and wastes space better used for data. This whitepaper will configure IPsec in Transport mode where only the IP payload is protected by IPsec and not the IP header and IP payload. IPsec policy configuration is probably the most intimidating thing about IPsec and one of the main reasons that it is not widely deployed today. Unfortunately, its reputation is well deserved. We will need to break it into three parts to cover it clearly. The first part is Packet Matching, the second part is the Action-on-Match, and the third part is the Authentication. 24

  • 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

24
Figure 22 - Printing with an IPsec Policy
Starting at the top and working down, we can see the how vital a role the IPsec policy plays in
determining which packets are protected and which are not.
An IPsec policy can specify that IP
packets don’t need IPsec and can be transmitted without IPsec protection.
In addition, the IPsec
policy can specify that IP packets should be discarded as well as IP packets that must be transmitted
with IPsec protection.
Another important point to note in the figure is that the IP packet that received IPsec protection has its
content encrypted.
This encryption provides confidentiality and is shown by the yellow color and the
brackets around TCP and Print Data.
Should this IP packet be captured by Wireshark, the contents in
yellow are unreadable and appear like random data.
In fact, the Wireshark capture won’t be able to
tell if this is a TCP packet or what protocols IPsec is carrying.
All Wireshark will be able to tell is that
it is an IPsec packet with the data protected via IPsec confidentiality (i.e., encryption).
NOTE: It is
possible to run IPsec in various modes that may not provide for confidentiality.
This whitepaper will
only be considering IPsec deployment where confidentiality and authentication are a requirement. In
addition, IPsec can be configured for Tunnel Mode, where the entire IP packet (IP header and
payload) is part of the protected IPsec payload, which is often done for VPNs. For the purposes of
Intranet security, this mode is unnecessary and wastes space better used for data.
This whitepaper
will configure IPsec in Transport mode where only the IP payload is protected by IPsec and not the IP
header and IP payload.
IPsec policy configuration is probably the most intimidating thing about IPsec and one of the main
reasons that it is not widely deployed today.
Unfortunately, its reputation is well deserved. We will
need to break it into three parts to cover it clearly.
The first part is Packet Matching, the second part
is the Action-on-Match, and the third part is the Authentication.