[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