On Mon, Oct 23, 2006 at 05:57:53PM +0200, marcelo bagnulo braun wrote: > Hi Dave, > > thank you very much for your detailed review, i think it has greatly > helped to improve the readability of the draft. My pleasure. Glad I could help. > 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... Comments in line (search for dmm>). thnx, --dmm > > > > 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? dmm> sure > > > 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... dmm> such examples would be very helpful. I'm still a little dmm> leary of the lack of "information hiding", although that has dmm> its ups and downs too... > > 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? dmm> understand. it wasn't a huge issue, just style, I suppse > ... > >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? dmm> I was just taking a look at that, and I guess its fine. > > > ... > > > >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? dmm> yes. Maybe exactly that text, or something like it, would clarify? > > > 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... dmm> ok, that wasn't clear to me when I first read the doc > > ... > 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? dmm> I'm not a secuity expert (duh :-)), but yes, it would seem so. > thanks again for your careful review... Any time. Its my pleasure. --dmm
Attachment:
pgpW8IFpENkx0.pgp
Description: PGP signature