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

Traffic Types, Advanced Options

Page 48 highlights

Figure 41 - Traffic Types The most problematic of all traffic for IPsec to handle is broadcast/multicast traffic. The premise around broadcast and multicast traffic is to send only one packet to multiple hosts without having to send each host a separate packet. IPsec cannot protect this traffic because there is not an easy way to do IKE negotiations with multiple hosts at the same time and have everyone agree on the same key. Therefore, when a broadcast/multicast packet is received and the IPsec policy states that the packet must be provided IPsec protection, HP Jetdirect will DROP the packet since it cannot meet the requirements of the IPsec policy. Because of the ubiquitous nature of broadcast/multicast traffic, HP Jetdirect has made some exceptions to important protocols to allow for proper operation when broadcast/multicast traffic is received. The traffic chosen is shown in Figure 42 - Advanced Options. Figure 42 - Advanced Options On this screen, protocols can be selected to bypass the IPsec policy for broadcast/multicast traffic or by unselecting them, not to bypass the IPsec policy. The default selections allow for proper operation of the network without too much exposure to security threats. This behavior is important to understand. If an administrator selects an IPsec policy where all IP addresses and all IP services are required to use IPsec, the HP Jetdirect device will still get DHCP configured. This behavior can be controlled through the screen in Figure 42, but is the default behavior. Where the advanced option screen suffers is for broadcast/multicast request packets that require a unicast response - protocols like SLP. Here, the request is allowed to bypass the IPsec policy, but the response is unicast and must follow the IPsec policy and could result in the packet using IPsec. If the requestor does not have a matching IPsec policy, the response is never received. Refer to Figure 43 for an SLP discovery example. 48

  • 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

48
Figure 41 – Traffic Types
The most problematic of all traffic for IPsec to handle is broadcast/multicast traffic.
The premise
around broadcast and multicast traffic is to send only one packet to multiple hosts without having to
send each host a separate packet.
IPsec cannot protect this traffic because there is not an easy way
to do IKE negotiations with multiple hosts at the same time and have everyone agree on the same key.
Therefore, when a broadcast/multicast packet is received and the IPsec policy states that the packet
must be provided IPsec protection, HP Jetdirect will DROP the packet since it cannot meet the
requirements of the IPsec policy.
Because of the ubiquitous nature of broadcast/multicast traffic, HP Jetdirect has made some
exceptions to important protocols to allow for proper operation when broadcast/multicast traffic is
received.
The traffic chosen is shown in Figure 42 – Advanced Options.
Figure 42 – Advanced Options
On this screen, protocols can be selected to bypass the IPsec policy for broadcast/multicast traffic or
by unselecting them, not to bypass the IPsec policy. The default selections allow for proper operation
of the network without too much exposure to security threats.
This behavior is important to
understand.
If an administrator selects an IPsec policy where all IP addresses and all IP services are
required to use IPsec, the HP Jetdirect device will still get DHCP configured.
This behavior can be
controlled through the screen in Figure 42, but is the default behavior.
Where the advanced option screen suffers is for broadcast/multicast request packets that require a
unicast response – protocols like SLP.
Here, the request is allowed to bypass the IPsec policy, but the
response is unicast and must follow the IPsec policy and could result in the packet using IPsec.
If the
requestor does not have a matching IPsec policy, the response is never received.
Refer to Figure 43
for an SLP discovery example.