[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-05.txt
Hi Dave,
thank you very much for your detailed review, i think it has greatly
helped to improve the readability of the draft.
I have included most of your suggestions in the next version 06 of the
draft.
Remaining issues that i have not included in the draft and required
additional discussion imho are commented below...
El 20/07/2006, a las 17:00, David Meyer escribió:
Folks,
In Montreal Kurtis asked me if I'd read through the base
documents for readability (so this is a bit gen-art-ish)
and content. Here's my first such reveiew.
My comments are in-line (search for dmm>).
Thnx,
--dmm
...
1. Introduction
...
1.5. Renumbering Implications
....
But IP addresses are also used as ULID, and making the communication
survive locators becoming invalid can potentially cause some
confusion at the upper layers. The fact that a ULID might be used
with a different locator over time open up the possibility that
communication between two ULIDs might continue to work after one or
both of those ULIDs are no longer reachable as locators, for example
due to a renumbering event. This opens up the possibility that the
ULID (or at least the prefix on which it is based) is reassigned to
another site while it is still being used (with another locator) for
existing communication.
dmm> what are there security implications of this, if any?
Jim Bound have raised similar concerns in his review, so i have deleted
the last two paragraphs of this section included below, eliminating the
possibility of keeping the ULID after a renumbering event.
would that be enough?
In the worst case we could end up with two separate hosts using the
same ULID while both of them are communicating with the same host.
This potential source for confusion can be avoided if we require
that
any communication using a ULID must be terminated when the ULID
becomes invalid (due to the underlying prefix becoming invalid). If
that behavior is desired, it can be accomplished by explicitly
discarding the shim state when the ULID becomes invalid. The
context
recovery mechanism will then make the peer aware that the context is
gone, and that the ULID is no longer present at the same locator(s).
However, terminating the communication might be overkill. Even when
an IPv6 prefix is retired and reassigned to some other site, there
is
a very small probability that another host in that site picks the
same 128 bit address (whether using DHCPv6, stateless address
autoconfiguration, or picking a random interface ID [11]). Should
the identical address be used by another host, then there still
wouldn't be a problem until that host attempts to communicate with
the same peer host with which the initial user of the IPv6 address
was communicating.
The protocol as specified in this document does not perform any
action when an address becomes invalid. As we gain further
understanding of the practical impact of renumbering this might
change in a future version of the protocol.
...
2. Terminology
Context forking A mechanism which allows ULPs that are aware of
multiple locators to use separate contexts for
dmm> a bit confusing, since ULPs shouldn't be aware of locators
dmm> in any event? what is an example of a ULP that would be
dmm> "locator-aware"?
this seems a fundamental issue with the concept of forking...
The idea of forking is to allow applications that "know better" to
actually manage the locators used for the communication through an
extended API. of course the basic idea is that apps are not aware of
locators, but in case of special apps that want to be able to do this,
this is how they do it. Several folks have brougth that this was
needed... maybe them can provide exmaples of such apps...
this is the same issue that you brought up in...
4.2. Context Forking
It has been asserted that it will be important for future ULPs, in
particular, future transport protocols, to be able to control which
locator pairs are used for different communication. For instance,
dmm> sort of violates the property that ULIDs appear to be
dmm> locators to the ULPs. What are the implications of
dmm> exposing the ULID/Locator mapping to the ULPs or other
dmm> applications that use the shim6 service?
...
4. Protocol Overview
...
The shim6 protocol operates in several phases over time. The
following sequence illustrates the concepts:
o An application on host A decides to contact B using some upper-
layer protocol. This results in the ULP on A sending packets to
B. We call this the initial contact. Assuming the IP addresses
selected by Default Address Selection [12] and its extensions
[13]
work, then there is no action by the shim at this point in time.
Any shim context establishment can be deferred until later.
dmm> inconsistent use of Host X and X to refer to the same
dmm> thing. scan the entire doc for this.
i am not sure about this....
we use Host A and host B and then we simply use A and B in order to
make the reading less loaded...
do you think it is unclear or a matter of style?
...
7. Establishing ULID-Pair Contexts
In all the cases the result is that the peer without state receives
a
shim message for which it has to context for the context tag.
dmm> BTW, inconsistent use of shim v. shim6
shim is used as the generic concept of a middle layer and shim6 is used
as the specific implementation of a shim described in this document.
These two terms should be used like this consistently in the whole
docuemnt, makes sense?
...
7.6. Context confusion
Since each end might garbage collect the context state we can have
the case when one end has retained the context state and tries to
use
it, while the other end has lost the state. We discussed this in
the
previous section on recovery. But for the same reasons, when one
host retains context tag X as CT(peer) for ULID pair <A1, B1>, the
other end might end up allocating that context tag as CT(local) for
another ULID pair, e.g., <A3, B1> between the same hosts. In this
case we can not use the recovery mechanisms since there needs to be
separate context tags for the two ULID pairs.
This type of "confusion" can be observed in two cases (assuming it
is
A that has retained the state and B has dropped it):
o B decides to create a context for ULID pair <A3, B1>, and
allocates X as its context tag for this, and sends an I1 to A.
Nordmark & Bagnulo Expires November 16, 2006 [Page
58]
Internet-Draft Shim6 Protocol May
2006
o A decides to create a context for ULID pair <A3, B1>, and starts
the exchange by sending I1 to B. When B receives the I2 message,
it allocates X as the context tag for this context.
In both cases, A can detect that B has allocated X for ULID pair
<A3,
B1> even though that A still X as CT(peer) for ULID pair <A1, B1>.
Thus A can detect that B must have lost the context for <A1, B1>.
The confusion can be detected when I2/I2bis/R2 is received since we
require that those messages MUST include a sufficiently large set of
locators in a Locator List option that the peer can determine
whether
or not two contexts have the same host as the peer by comparing if
there is any common locators in Ls(peer).
dmm> not really sure how this works. Is it not possible to have
dmm> a situation where Ls_i(peer) \intersect Ls_j(peer) is empty
dmm> (where Ls_1(peer),...,Ls_n(peer) is the sequence of changing
dmm> locator sets for peer)? Or is the "sufficiently slowly
dmm> changing locator sets" assumption operative here?
the assumption here is that there is no situation of merging hosts,
meaning that if two contexts are initiated with a disjoint set of
locators, they will remain disjoint during the lifetiem of the context,
and the situation where two contexts have disjoint sets and then later
on one of them adds new locators that interject with another previously
disjoint context is not supported. This is what the above assumption is
expressing... makes sense?
The requirement is that the old context which used the context tag
MUST be removed; it can no longer be used to send packets. Thus A
would forcibly remove the context state for <A1, B1, X>, so that it
can accept the new context for <A3, B1, X>. An implementation MAY
re-create a context to replace the one that was removed; in this
case
for <A1, B1>. The normal I1, R1, I2, R2 establishment exchange
would
then pick unique context tags for that replacement context. This
re-
creation is OPTIONAL, but might be useful when there is ULP
communication which is using the ULID pair whose context was
removed.
dmm> what happens if an "old" I1 was floating around and gets
dmm> there before the "new" I1 and still within I1_TIMEOUT?
I1 new and I1 old are supposed to be equal, right? so if the first one
arrives first than the second it shouldn't matter i guess...
...
7.20. Receiving I2bis messages and sending R2 messages
A host MUST silently discard any received I2bis messages that do not
satisfy all of the following validity checks in addition to those
specified in Section 12.2:
o The Hdr Ext Len field is at least 3, i.e., the length is at least
32 octets.
Upon the reception of an I2bis message, the host extracts the ULID
pair and the Forked Instance identifier from the message. If there
is no ULID-pair option, then the ULID pair is taken from the source
and destination fields in the IPv6 header. If there is no FII
option
in the message, then the FII value is taken to be zero.
dmm> is there a way to get a I2bis with no ULID-pair option but
dmm> with a (non-zero) FII option? If so, which case is that? If not,
dmm> what does the host do if it receives that?
both scenarios are supported
the packet can have a ULID option or not and may have a FII option or
not. all 4 combination are possible...
...
16. Security Considerations
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.
dmm> why can't I just search the 2^47 space? I suppose an
dmm> implementation will detect this.
we haven't considered the possibility of this attack
the attack that the protocol is protected (sort of) is a memory
consuption doS attack, in which the attacker generates many shim6
context in order to exaust the memory of the victim. the protection
against this attack is that a 4 way handshake is required to establish
the shim6 context. This implies that the attacker needs to spend
additional resources in order to launch the attack, these resourses
would also be needed to launch the CT exahustion attack that you
describe, do you think this would be enough protection for this case?
thanks again for your careful review...
marcelo