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

SLP Discovery

Page 49 highlights

Figure 43 - SLP Discovery We can see some of the challenges with IPsec policy for the HP Jetdirect device. Luckily, we will describe a process for handling these challenges. Let's look at the other services and devices on the network as they may add further constraints to our HP Jetdirect IPsec policy. What about the desktops and laptops that print to HP Jetdirect devices using HP's Universal Printing Driver? What are some of the challenges there? Assuming that our company's security policy requires print traffic to be protected, we have two concerns: (a) Make sure the HP Jetdirect device does not allow non-IPsec print traffic and (b) make sure that all desktops and laptops in my Active Directory environment have an IPsec policy that protects their print traffic. The first one can be incorporated as a requirement of the HP Jetdirect IPsec policy. The second one can be done via IPsec policy distribution through the Active Directory. The form that this Active Directory distributed policy takes is important. If we list every IP address of all the printers and MFPs in the company, it will be unmanageable as devices are added, removed, and changed. If we say "all ip addresses", we will be impacting normal desktop and laptop functions that have nothing to do with printing. We do have a solution here as well; let's talk about some more devices and services first. DNS and WINS are name resolution services that many networking devices utilize. The fundamental premise of name resolution is to take a name that people know (e.g., printer.example.com) and turn it into an IP address that devices can use. Some of these devices are IPsec capable and some are not. If we say that "all devices" must support IPsec to utilize these name resolution services, we will have caused a great deal of problems our network administrator! If we use an IPsec policy to only protect these services when communicating with certain clients that support IPsec, we also have created a management nightmare. If we say that clients that are capable of IPsec should use IPsec and clients that are not should not have to use it, we are left to wonder why we are even protecting this traffic with IPsec anyway since we cannot guarantee that anything is ever actually protected - probably not what the writer of the company's security policy had in mind. If we don't protect WINS/DNS with IPsec, can't someone do a WINS spoof or DNS spoofing attack and steal our IPsec protected print jobs? - NO! Our famous attacker Jane can do the spoof attack and get clients to talk to the wrong IP address, but Jane still doesn't have the correct IKE authentication information. Therefore, the clients will not establish IPsec protected connections with them. This important piece of information may allow us to avoid IPsec management headaches by avoiding IPsec on these name resolution protocols and allowing IPsec to do its job on the traffic we are interested in, such as print traffic. Specialty services like Web Jetadmin, Digital Send Service, etc... often make the case for a separate server to run these services dedicated to the printing and imaging management. As long as the server is dedicated to these services, we are able to lock it down with IPsec much better than if it is providing multiple services to a wide variety of clients. 49

  • 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

49
Figure 43 – SLP Discovery
We can see some of the challenges with IPsec policy for the HP Jetdirect device.
Luckily, we will
describe a process for handling these challenges.
Let’s look at the other services and devices on the
network as they may add further constraints to our HP Jetdirect IPsec policy.
What about the desktops and laptops that print to HP Jetdirect devices using HP’s Universal Printing
Driver?
What are some of the challenges there?
Assuming that our company’s security policy
requires print traffic to be protected, we have two concerns: (a) Make sure the HP Jetdirect device
does not allow non-IPsec print traffic and (b) make sure that all desktops and laptops in my Active
Directory environment have an IPsec policy that protects their print traffic.
The first one can be
incorporated as a requirement of the HP Jetdirect IPsec policy. The second one can be done via IPsec
policy distribution through the Active Directory.
The form that this Active Directory distributed policy
takes is important.
If we list every IP address of all the printers and MFPs in the company, it will be
unmanageable as devices are added, removed, and changed.
If we say “all ip addresses”, we will
be impacting normal desktop and laptop functions that have nothing to do with printing.
We do
have a solution here as well; let’s talk about some more devices and services first.
DNS and WINS are name resolution services that many networking devices utilize.
The fundamental
premise of name resolution is to take a name that people know (e.g., printer.example.com) and turn it
into an IP address that devices can use.
Some of these devices are IPsec capable and some are not.
If we say that “all devices” must support IPsec to utilize these name resolution services, we will have
caused a great deal of problems our network administrator!
If we use an IPsec policy to only protect
these services when communicating with certain clients that support IPsec, we also have created a
management nightmare.
If we say that clients that are capable of IPsec should use IPsec and clients
that are not should not have to use it, we are left to wonder why we are even protecting this traffic
with IPsec anyway since we cannot guarantee that anything is ever actually protected – probably not
what the writer of the company’s security policy had in mind.
If we don’t protect WINS/DNS with
IPsec, can’t someone do a WINS spoof or DNS spoofing attack and steal our IPsec protected print
jobs?
– NO!
Our famous attacker Jane can do the spoof attack and get clients to talk to the wrong
IP address, but Jane still doesn’t have the correct IKE authentication information.
Therefore, the clients
will not establish IPsec protected connections with them.
This important piece of information may
allow us to avoid IPsec management headaches by avoiding IPsec on these name resolution protocols
and allowing IPsec to do its job on the traffic we are interested in, such as print traffic.
Specialty services like Web Jetadmin, Digital Send Service, etc… often make the case for a separate
server to run these services dedicated to the printing and imaging management.
As long as the
server is dedicated to these services, we are able to lock it down with IPsec much better than if it is
providing multiple services to a wide variety of clients.