[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
Hi Pekka,
thank you very much for this in-depth review, i will try to address oem
of your comments...
El 31/03/2006, a las 12:11, Pekka Savola escribió:
substantial
-----------
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 ?
Well, i guess that what needs to be analyzed is the scope of this
time-shifted attacks that you are considering. In other scenarios like
MIP, the time-shifted attacks that have been considered as criticial
are the redirection time-shifted attacks, where the attacker manages to
be able to add new locator to the locator set after he has left the on
path location. This means that the attacker that once was on the path
is able to redirect the traffic after he has left the on path location.
This is a serious attack and it is not possible to do that in the shim6
protocol (thanks to the HBA/CGA protection)
However, as you mention, there are some time-shifted attacks that would
be possible. In particular, it would be possible for an attacker that
once was on the path to send a payload message that is protected by the
context tag. This means that the attacker can insert data packet inside
an established communication. This has the same effect of sending
packets with spoofed source address, right? Currently the only defense
against this is ingress filtering, which may or may not be deployed.
With the shim solution, the attacker needs to be on path and catch at
least one of the packets that carry to context tag. Then it can leave
the path and he will be able to inject packets that the shim layer will
translate into the proper source address. I would argue that it is
probably easier to try to send packets with the spoofed source address
than trying to intercept one of the shim6 establishment packets and
then move away and inject packets in an ongoing communication.
Especially, considering that those packets are likely to be discarded
by higher layers, since they do not belong to any established
communication. My perception of this is that the threat is similar to
the current situation, if not less. Note that this could be easily
solved by checking that the source locator is included in Ls(peer) but
this has several difficulties in its own in the protocol functioning,
and it doesn't seem to be worthy imho
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.
rather than the information protected is not very high, i would say
that it would be easier for the attacker to actually send the I1
messages and get new validators from the peer, rather than doing all
this work,
But these considerations should be
spelled out.
Agree, i guess we could also mention that the secret value could also
be changed from once in a while making this attractive this attack,
since the secret obtained would only be valid for a limited lifetime
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?
I am not sure why this is a security concern...
but as currently defined, the peer that it is not willing to initiate a
shim context could simply drop the I1 messages, that will be
retransmited a couple of times and then the initiator will move this
context to E-failed state, where it will stay for a period. After that,
it will move to IDLE state and retry again.
If he wants to be left alone for a longer period, it could reply with a
ICMP error, so the initiator will move to NO-SUPPORt state and stay
there for even longer.
Would this be enough or do you think better support is required?
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.
well, this was discussed in the AMS interim meeting and actually i
proposed that we could take an approach similar to IKEv2, where they
fall back to require a prior contact proof in the case the node
considers to be under attack.
So by default, context estbalishment would consists only in I2 and R2,
and if the node considers to be under attack, it starts requiring the 4
way exchange. The nice thing is that the I2 packet carries all the
information required of the I1, so at the end, the 4 way exchenge would
be I2,R1, I2, R2
The difficult part is how to detect that a node is under attack,
especially if the resulting attack consists in 2 way exchange.
I mean, in the case of TCP 3 way exchange, an easy way to detect
attacks is to measure the number of unfinnished TCP connection
establishment. If the number is high, it is likely to be an attack.
In the case of a 2 way handshake, you don't have this possibility. In
addition, the number of received connection requests may heavily vary
from one small client to a big server, so it is hard to define a
threshold to detect potential attacks.
Of course you can take into account what context are associated with
exsiting TCP connections and consider that these ones are not part of
the attack and so on. But in any case, i guess this is the tricky part.
In the AMS meeting, the proposal was to leave the 4 way handshake in
the base spec and allow future extensions of the shim6 protocol for
supporting this.
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...
agree, we could include some words in the line that i wrote above,
would that be ok?
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?"
section 9. Teardown of the ULID-Pair Context deals with this point and
it is left open to the implementations how to decide when perform
garbage collection. Some guidelines are provided though...
...
Thus it is RECOMMENDED that implementations minimize premature
teardown by observing the amount of traffic that is sent and received
using the context, and only after it appears quiescent, tear down the
state. A reasonable approach would be not to tear down a context
until at least 5 minutes have passed since the last message was sent
or received using the context.
do you think that additional guidance is needed?
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' ?
this is also up to the implementations, but are you suggesting we
provide some guidance about the lifetime of a responder nonce? like a
maximum nonce lifetime or similar?
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.
ok for that error code, do you have another one in mind?
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?
well, all the options have to have the format defined in section 5.14
whcih is basically a TLV format. In addition, it contains the C flag,
that defines whether the option is criticial or not and if it must be
recognized.
what do you think that something is missing?
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.
ok
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.
well, this is in the case that new message formats are defined. We are
assuming that they will contain the context tag. In this case, if they
don't contain the context tag, it won't be possible to properly
generate the R1bis packet...
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?
yes, but it would be somehow strange to add new locators if you use
HBAs, right? i mean, if you use HBAs the locator set is static. You
could just include a subset on the HBA set in the locator set option
initially exchanged and later on add new locators of the set, i guess,
but i am not sure if this makes much sense, but we could add a
clarification about this point if you think it would be useful
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?
yes forever seems a bit long i guess
I1_RETRIES_MAX
==> you didn't specify the constant...
ok
editorial
---------
Level 3 multihoming shim protocol
==> how about "Layer 3 Multihoming Shim Protocol for IPv6" ?
well, v4 locator extensions are being proposed....
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.
well, i think it is important to stress that what we want to avoid is
announcing specific prefixes for multihomed sites, which is clearer in
the current writing imho, what is in the proposed rephrasing that you
want to improve?
...
The reachability detection and failure detection, including how a
new
==> remove the first "detection" as unnecessary.
ok
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/ ?
neither?
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/
ok
The proposal uses an multihoming shim layer within the IP layer,
==> s/an/a/
ok
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/
ok
The responder can choose exactly what input uses to compute the
validator,
==> s/uses/is used/
ok
7.1 Uniqness of Context Tags
==> s/Uniq/Unique/
ok
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".
ok
If any of the above verifications fails, then the host silently
discard the message and it has completed the I2 processing.
==> s/discard/discards/
ok
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/
ok
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.)
ok
thanks, marcelo
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings