Firewall "uniformity" issue

[Erik Nordmark <erik.nordmark@sun.com>]

Shim6 will introduce:
1. A control protocol used to
	- detect whether or not the peer supports shim6
	- establish state in the shims; the context setup protocol
	- test which locator pairs work

2. A way to carry a context tag with data packets, so that the receiver 
can determine whether and with which ULIDs replace the locators in the 
received packet.

Existing IPv6 firewalls are of course not aware of shim6, but we can 
assume that they do not out of hand reject packets based on the flow 
label field. But they might filter based on UDP ports, extension 
headers, destination options header, or the options contained in the 
destinations options header.

Thus we can potentially end up with a case where 1 or 2, but not the 
other, make it through the firewall (of course, we also have the case 
when both or neither make it through, but those don't require extra care 
 :-) )

The case when #1 makes it through, but #2 is blocked by the firewall is 
a bit undesirable, because the context setup protocol will think that it 
can fail over to using a different locator pair, and it can test that 
the alternative locator pair(s) are working, but when it starts sending 
data packets using an alternate, those data packets will be dropped by 
the firewall.

Thus it seems desirable, if the data packets using alternate locators 
are going to be dropped by the firewall, try to construct the control 
protocol so those packets would be dropped by the firewall as well. That 
way shim6 would know there is no use in trying alternate locators.


For the case when #2 is handled by overloading the flow label field, 
this proposal doesn't add any restrictions on #1, because we assume 
existing firewalls will not drop packets based on the value of the flow 
label field (even if the IP address fields change).

In in the case when #2 is a new extension header, or a new destination 
option, this leads to suggesting that #1 be carried using the same 
mechanism as #2.
For instance, if the data packets (after a failure has caused switching 
to a different locator pair), are embellished with a new extension 
header (IP protocol value XX), then it makes sense to do the context 
establishment and testing using IP protocol value XX as well.
Likewise, if the data packets are embellished with the new Destination 
option (value YY), then it makes sense to do #1 using packets that carry 
that Destination option as well.

Of course, once there are shim6 aware firewalls, we don't know how they 
will behave. But we could at least recommend that they take this issue 
into consideration, by recommending
1) that they not block shim6 by default, but instead look at the carried 
(TCP, UDP, etc) payload
2) if they need to block shim6, block the context establishment and 
testing parts of the protocol and not just the data packets

Comments?
    Erik