[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt
On Fri, 24 Mar 2006, Geoff Huston wrote:
This note starts the WG Last Call for comments on
draft-ietf-shim6-proto-04.txt, "Level 3 multi-homing shim
protocol".
I read the spec on the way back from the IETF. In general, it was a
rather fluent read. What I most kept thinking through the read were
security implications which weren't described or referred to from the
body of the draft, but many of those were indeed mentioned in the
security considerations. Maybe some forward pointers could have
helped.
Other than that, there were a couple of issues described below.
I think the most fundamental one was that I'm not sure whether the
4-way handshake is useful or even necessary, given that we don't even
want to establish the context before the session is already up (which
would mitigate DoS concerns). On the other hand, if we already need
to prepare for an Extended Shim Design....
substantial
-----------
1) On IP multicast: it's not clear whether the text only applies to
Any-Source-Multicast, rather than also to SSM. The IP addresses do matter
with SSM, as the hosts specify from which IP address they wish to receive
the stream (and the multicast routing then goes to that IP address's
designated router to set up the forwarding state). With SSM, changing IP
addresses at the sender end would imply that all the receivers will need
to redo the MLD and PIM signalling. With ASM, this happens automatically.
While in theory it would be possible to apply the shim re-mapping of
the IP address fields between ULIDs and locators, the fact that all
the multicast receivers would need to know the mapping to perform,
makes such an approach difficult in practice. Thus it makes sense to
have multicast ULPs operate directly on locators and not use the
shim. This is quite a natural fit for protocols which use RTP [14],
since RTP already has an explicit identifier in the form of the SSRC
field in the RTP headers. Thus the actual IP address fields are not
important to the application.
2) carrying the context tag opens the avenue for time-shifting attacks
(e.g., data insertion into a session) after an attacker has moved from
on-path to off-path ?
o Every control message of the shim6 protocol, past the context
establishment, carry the context tag assigned to the particular
context. This implies that an attacker needs to discover that
context tag before being able to spoof any shim6 control message.
Such discovery probably requires to be along the path in order to
be sniff the context tag value. The result is that through this
technique, the shim6 protocol is protected against off-path
attackers.
3) The spec IMHO needs to say more about application framing impacts, as a
result of adding the shim to some packets (well, we have been rather vague
about this in the past, RFC4038 sec 5.4.2). TCP-like protocols are not a
big problem because the stack can just adjust to whatever value is
appropriate, but protocol such as UDP where the user needs to specify this
are trickier. You should probably describe the required modifications
to the implementations fragmentation handling code.
Triggered by this text, but there was also discussion in 11.1 as well as
section 15, but the more appropriate place for discussing it
should be a new section 11.2 ?
Layering the fragmentation header above the multihoming shim makes
reassembly robust in the case that there is broken multi-path routing
which results in using different paths, hence potentially different
source locators, for different fragments. Thus, effectively the
multihoming shim layer is placed between the IP endpoint sublayer,
which handles fragmentation, reassembly, and IPsec, and the IP
routing sublayer, which selects which next hop and interface to use
for sending out packets.
4) There seem to be a number of minor attacks, and/or non-issues or residual
threats which might be good to spell out better in the security
considerations sections.
4.1) The only hash input that an attacker could not affect is the secret
value, and even that is static. As the responder nonce is basically
incremented based on the shim exchanges of the responder, the attacker can
predict that as well. With this kind of information,
(after some tries, and possibly other ways of obtaining knowledge how long
the host has been up) a) the attacker should be able to figure out the
secret as well, and b) given that the attacker can choose so many bits in
the hash function input, it should be reasonable to find hash function
collisions as well (especially with weaker hash functions).
That said, both of these issues may be no-op's because the value of the
information protected is not very high. But these considerations should be
spelled out.
4.2) what about the scenario where the initiator wishes to establish shim6
sessions when the other party isn't (yet) willing to do so? (Think about
large content providers.) What are the graceful mechanisms to achieve this?
4.3) Following from 4.2), you really don't need the 4-way handshake under
normal circumstances. When you wish to establish the shim6 state, the peer
has already proven its desire for genuine communication by opening the TCP
connection and using it for some time. If it wanted to attack, it wouldn't
be using SHIM at all, just TCP. So, you might be able to simplify the SHIM
exchange under normal situations. On the other hand, the responders need
the mechanisms to deal with the cases where they don't want to establish
shim6 state yet (e.g., before the TCP connection is even established, or
whatever), or want to use a secure SHIM exchange variant.
4.4) 47-bit context tags are the most troublesome issue to me. You should
be more explicit what the effects of guessing (or knowing, from being on the
path) the tag are, 'cause disruption' is a bit vague. The problem with
these is that there is that from the network security manager's perspective,
there is no way to do any kind of filtering on the received packets -- IP
addresses, port numbers, etc. lose their relevancy when protecting hosts
from the big bad world. Some may even consider this a feature...
semi-substantial (not sure if these are real issues or not)
----------------
------------- R1 --------------->
Left old context
in ESTABLISHED
==> at this point, I kept thinking, "so.. isn't there any timeout for
contexts in ESTABLISHED state..? Does it stay there forever?"
Next the host verifies that the Responder Nonce is a recent one, and
that the Responder Validator option matches the validator the host
would have computed for the ULID, locators, responder nonce, and FII.
==> how do you define 'a recent one' ?
If the host receives an ICMP error with "payload type unknown" (type
4, code 1) and the included packet is the I1 message it just sent,
then this is a more reliable indication that the peer ULID does not
implement shim6. Again, in this case, the host should remember to
not try again to establish a context with that ULID. Such negative
caching should retained for at most ICMP_HOLDDOWN_TIME, which should
be significantly longer than the previous case.
==> you should probably apply the same policy for certain other ICMP errors,
at least type 1 code 1 "Communication with destination administratively
prohibited", implying the protocol may be filtered at the firewall.
semi-editorial
--------------
Next Header: NO_NXT_HDR (59).
==> I'd make this 'Normally...' or the like, so that it would be clearer
that it might be OK for future extensions (if any) to also put in some other
value if they wanted to.
The following options are defined for this message:
==> but this is not an exhaustive list. Do you already specify somehow how
you will treat yet-to-be-specified options? How do you parse the options
that are not on the lists?
All of the TLV parameters have a length (including Type and Length
fields) which is a multiple of 8 bytes. When needed, padding MUST be
added to the end of the parameter so that the total length becomes a
multiple of 8 bytes. This rule ensures proper alignment of data. If
padding is added, the Length field MUST NOT include the padding. Any
added padding bytes MUST be zeroed by the sender, and their values
SHOULD NOT be checked by the receiver.
==> I think this specification of padding adding is sub-optimal: why do you
say "the Length field MUST NOT include the padding" at all? Do you want to
cover the scenario where the length field says X, but there is Y (>>X)
amount of extra padding? Specifying that padding up to 8 bytes can be
stated in much simpler terms.
7.3 Normal context establishment
The normal context establishment consists of a 4 message exchange in
the order of I1, R1, I2, R2 as can be seen in Figure 24.
Initiator Responder
IDLE IDLE
------------- I1 -------------->
I1-SENT
<------------ R1 ---------------
IDLE
------------- I2 -------------->
==> at this point, I wondered, "how can the responder stay idle? it needs
to remember _something_", so maybe a forward pointer to the security
discussion (i.e., a global secret value) could be useful.
We assume that all the incoming packets that trigger the generation
of an R1bis message contain a locator pair (in the address fields of
the IPv6 header) and a Context Tag.
==> there is no need to "assume" anything, as this should already happen due
to the nature of shim6. Reword e.g., "The locator pair is extraced from the
source and destination IP addresses" or whatever.
The Update Request message can include
just a Locator List option, to convey the new set of locators (which
requires a CGA signature option as well), just a Locator Preferences
option, or both a new Locator List and new Locator Preferences.
==> The CGA signature options is only applicable w/ new locators when you
use non-HBA CGA addresses, right?
Should there be no response, the retransmissions continue forever.
The binary exponential backoff stops at MAX_UPDATE_TIMEOUT.
==> "forever" is a rather harsh way to say that. "until the shim state is
discarded" or something?
I1_RETRIES_MAX
==> you didn't specify the constant...
editorial
---------
Level 3 multihoming shim protocol
==> how about "Layer 3 Multihoming Shim Protocol for IPv6" ?
The SHIM6 protocol is a layer 3 shim for providing locator agility
below the transport protocols, so that multihoming can be provided
for IPv6 with failover and load sharing properties, without assuming
that a multihomed site will have a provider independent IPv6 address
prefix which is announced in the global IPv6 routing table.
==> the latter part is not important for this spec, so almost the same thing
would be to say:
The SHIM6 protocol is a layer 3 shim for providing locator agility
below the transport protocols, so that multihoming can be provided
for IPv6 with failover and load sharing properties, without assuming
that a multihomed site will have a globally routable provider
independent IPv6 address prefix.
...
The reachability detection and failure detection, including how a new
==> remove the first "detection" as unnecessary.
o Do not require an extra roundtrip up front to setup shim specific
state.
==> remove "Do" for style consistency?
But it is not a goal to try to make communication
survive a renumbering event (which causes all the locators of a host
to change to a new set of locators). This proposal does not attempt
to solve the, perhaps related, problem of host mobility.
==> s/proposal/proposal also/ ?
Worst case we could end up with two separate hosts using the same
ULID while both of them are communicating with the same host.
==> s/Worst/In the worst/
The proposal uses an multihoming shim layer within the IP layer,
==> s/an/a/
2), there is a choice whether the shim applies inside the tunnel or
outside the tunnel, which effects the location of the shim6 header.
==> s/effects/affects/
The responder can choose exactly what input uses to compute the
validator,
==> s/uses/is used/
7.1 Uniqness of Context Tags
==> s/Uniq/Unique/
Host A Host B
IDLE IDLE
-\
I1-SENT---\
---\ /---
--- I1 ---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<---
==> could this look nicer if the diagrams were drawn with more
straight lines, like:
IDLE IDLE
-----------.
\ .-----
I1 I1
\ /
X
/ \
'----->
...
If the host receives an ICMP error with "payload type unknown" (type
4, code 1) and the included packet is the I1 message it just sent,
==> in a couple of places, the error name is actually "Unrecognized Next
Header type encountered".
If any of the above verifications fails, then the host silently
discard the message and it has completed the I2 processing.
==> s/discard/discards/
o The HBA technique [7] for verifying the locators to prevent an
attacker from redirecting the packet stream to somewhere else.
o Requiring a Reachability Probe+Reply before a new locator is used
==> if you want consistent style, I'd s/for verifying/verifies/,
s/Requiring/Requires/ (not sure about this one...)
specification. Special thanks to the careful comments from Geoff
Houston and Shinta Sugimoto on earlier versions of this draft.
==> s/Houston/Huston/
Appendix C. Change Log
==> add a note to the rfc-editor to remove this upon publication (it would
actually be best if this was the last appendix, so the appendix numbers
wouldn't get shuffled when this gets removed.)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings