Shim6: Level 3 Multihoming Shim Protocol for IPv6
draft-ietf-shim6-proto-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the Abstain position for Cullen Jennings |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the Abstain position for David Ward |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Ross Callon |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Ronald Bonica |
2009-04-21
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-04-16
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-04-16
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-04-15
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-04-15
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-03-18
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-03-11
|
12 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-03-11
|
12 | (System) | IANA Action state changed to In Progress |
2009-03-11
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-03-11
|
12 | Amy Vezza | IESG has approved the document |
2009-03-11
|
12 | Amy Vezza | Closed "Approve" ballot |
2009-03-11
|
12 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko |
2009-03-11
|
12 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-03-11
|
12 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-03-08
|
12 | Jari Arkko | Waiting on Tim to look at the last Discuss (should have been addressed by the latest version) |
2009-02-17
|
12 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-02-15
|
12 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2009-02-15
|
12 | Jari Arkko | Waiting for Pasi to look at the new version and its IPsec text. |
2009-02-06
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-02-06
|
12 | (System) | New version available: draft-ietf-shim6-proto-12.txt |
2008-12-21
|
12 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2008-12-21
|
12 | Jari Arkko | Expecting one more change based on Pasi's comments. |
2008-12-16
|
12 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-12-15
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-12-15
|
11 | (System) | New version available: draft-ietf-shim6-proto-11.txt |
2008-07-22
|
12 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss by Ron Bonica |
2008-07-20
|
12 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2008-07-20
|
12 | Jari Arkko | Still needs a revision to bring in the resolution from discussions between Pasi and Erik, on IPsec issues. |
2008-06-24
|
12 | Jari Arkko | State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Jari Arkko |
2008-06-18
|
12 | David Ward | [Ballot comment] I support Cullen's list of issues and will let him hold them. These need to be answered/solved. |
2008-06-18
|
12 | David Ward | [Ballot Position Update] Position for David Ward has been changed to Abstain from Discuss by David Ward |
2008-04-25
|
12 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2008-04-25
|
12 | Jari Arkko | External party. Waiting for Dave Ward's explanation. |
2008-03-31
|
12 | Pasi Eronen | [Ballot discuss] [Taking Sam's discuss] Overall this is a well written document and I appreciate the work that has gone into it. First, I'm trying … [Ballot discuss] [Taking Sam's discuss] Overall this is a well written document and I appreciate the work that has gone into it. First, I'm trying to figure out if someone with HBA locators can use the update message to update their locator set. I am probably just missing it, but is there text in this spec (as apposed to the HBA spec) that requires if HBA verification is used, all the locators are HBAs? Presumably this requirement is intended to exist? Unfortunately, there is a significant conflict between this document and RFC 4301.This document has an architecture of the IP layer where there is a sub-layer responsible for routing and a sub-layer responsible for ULP interactions, fragmentation, etc. The shim is inserted between these two layers. The document assumes that IPsec processing happens in the layer that does fragmentation--above the shim. RFC 4301 also has a detailed architecture of IP and in particular IPsec processing. They aren't the same. RFC 4301 divides interfaces into protected and unprotected interfaces. IPsec processing and the SPD are consulted when a packet crosses from a protected interface to an unprotected interface. In the RFC 4301 model you need to understand what interface a packet will be routed out on before making a decision about IPsec processing. This is an important part of the IPsec model. I may have two paths out of my system. One over a trusted network and one over an untrusted network. If a link or path fails and the trusted network is no longer available IPsec processing may suddenly be required. However the reasoning in the shim6 draft about why you may want the shim below IPsec also applies in some configurations. What is clear to me is we have significantly more work to do on this issue. It is also clear that if shim6 is going to change the IPsec processing model, RFC 4301 must be updated either by this spec or by some document normatively referenced by this spec. Finally, shim6 may not change the IPsec processing model without involving the security community and getting appropriate review. [additional comments by Pasi] IPsec policies can be about identifiers visible to ULP (e.g., if you configure a client application to talk to server at particular IP address, you'd also configure the SPD to require ESP for that traffic), or it can be about locators used for delivering packets (e.g., some traffic might be going over a leased line that's considered OK enough without ESP). RFC 4301 didn't have to make this distinction, but it seems that simply putting shim6 below IPsec works better for former kind of policies, and less well for the latter kind. |
2008-03-31
|
12 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-02-16
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Abstain from Discuss by Cullen Jennings |
2008-02-16
|
12 | Cullen Jennings | [Ballot comment] * Many of the mechanisms that are required to make this safe to use are not specified enough to be implementable and simply … [Ballot comment] * Many of the mechanisms that are required to make this safe to use are not specified enough to be implementable and simply place holders for future work. Forking for example. * Most of the problems with NATs arise out of the application using an address identifier which is not the one some parts of the network are using and in the process break the end to end principal. SHIM6 will have very similar properties and problems. * The deployment model requires both ends to support SHIM6 but offer little or no incentive for either end to deploy first. * It's unclear how it will interact with say firewalls that time out alternative path. I understand the arguments that firewalls may not allow unknown protocols to flow through them but initial deployment of ipsec showed that at least for some firewalls this is allowed. * The scope of applicability is very narrow. If the goal is only keep long lived sessions up during multihomed cutover, most applications don't need to do this and just form new connections. The ones that do need this would likely be better served by something like SCTP which did not have the NAT characteristics. * The lack of a mandatory way for upper level protocols to be able to control and understand what is going on at this level will make it hard for applications to understand why things are failing. An example of this is how SHIM6 eats some but not all of the ICMP messages. I look forward to debugging and trying to figure out why I see ICMP message on the wire and some times the message is delivered to the apps (if shim6 has not started) and some times it is not. * Requires unspecified heuristics to decide when to use it. This is not a problem so much as the heuristics are clearly application dependent yet have to be implemented at more the kernel level. * It moves traffic engineering decisions to an end host that has no idea of the global information needed to make reasonable TE decisions. I understand argument that DNS round robin does the same thing but even DNS servers some times looked at global state to decide what to return. Note I am not complaining that it moves what TE from operators to users - I am worried about moving it from a place where the information to do it exists to a place where the information is unlikely to exist. It is possible that over time people will find solutions to the above problems and develop a better understanding of which of these do not impact other protocols in a negative way. At that point I'd be fine to move to PS but right now I believe this is better as experimental. |
2008-02-16
|
12 | Cullen Jennings | [Ballot discuss] I see this work as a stage along the way to having a full solution and worth publishing but only as experimental because … [Ballot discuss] I see this work as a stage along the way to having a full solution and worth publishing but only as experimental because I believe it would cause harm to a significant set of applications if widely deployed as currently specified. * This breaks applications that use MIDCOM style architectures and would be harmful to these applications if it saw widespread deployment. I'm glad to provide more details about this but many applications want to be able to tell things like logging and recording systems what flows they are using and this will break them without the applications being able to even know when or why their flow changed. * It's dramatically changes the underlying model of timing of failover which will interact very poorly with timers in layer 3 and above protocols. This is part of the reason for example that the drafts say it should not be used with SCTP. But what about other applications that have the same type of behavior as SCTP at the application layer? How would shim6 know what applications it was safe for and which ones were not. Application are not in total control of the host and their is not a single application per host. This may work for some environments but we can not expect end users to know if it would be safe to use SHIM6 for all of their applications or not. I have entered this as a discuss simply for logging and tracking purposes of my abstain position. I am happy to discuss my concerns but I don't think this is a particularly actionable discuss. |
2008-02-16
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Abstain by Cullen Jennings |
2008-02-14
|
12 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Discuss by Ross Callon |
2008-02-14
|
12 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2008-02-14
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-02-14
|
10 | (System) | New version available: draft-ietf-shim6-proto-10.txt |
2008-01-24
|
12 | Chris Newman | [Ballot comment] After reviewing draft-ietf-shim6-app-refer, it's clear the application issues have been considered appropriately, although it's unfortunate that draft has expired. If this were … [Ballot comment] After reviewing draft-ietf-shim6-app-refer, it's clear the application issues have been considered appropriately, although it's unfortunate that draft has expired. If this were to deploy widely, I suspect applications (particularly servers) would need to use OS APIs for this information at least for logging if not for other functions. |
2008-01-24
|
12 | Chris Newman | [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Abstain by Chris Newman |
2008-01-24
|
12 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-01-10
|
12 | Jari Arkko | Telechat date was changed to 2008-01-24 from 2008-01-10 by Jari Arkko |
2008-01-10
|
12 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Jari Arkko |
2008-01-10
|
12 | Lars Eggert | [Ballot comment] > 1. Introduction Assume that a SHIM6 host has multiple network interfaces, each of which has multiple IP addresses out of … [Ballot comment] > 1. Introduction Assume that a SHIM6 host has multiple network interfaces, each of which has multiple IP addresses out of different prefixes. Assume this host is communicating with another such host. Is SHIM6 limited to failing over connections between those hosts between IP addresses that are associated with a network single interface pair only, or is SHIM6 providing a mechanism for connections to fail over from one network interface pair to another? (I re-read the intro three times, but this isn't clear to me. I believe the intent is the latter?) Section 2.2., paragraph 1: > A, B, and C are hosts. X is a potentially malicious host. > FQDN(A) is the Fully qualified Domain Name for A. > Ls(A) is the locator set for A, which consists of the locators L1(A), > L2(A), ... Ln(A). A host A can have multiple FQDNs, each of which maps into some subset of Ls(A). Also, MUST Ls(A) always contain *all* addresses of the host, including link-local and other special-case addresses? Is it allowed to eliminate some addresses from Ls(A), e.g., due to management or local policy? Section 2.2., paragraph 2: > The locator set in not ordered in any particular > way other than maybe what is returned by the DNS. So is the set ordered, or is it not ordered? (Unclear what "other than maybe" tries to say here.) Also, as stated above, there may be multiple FQDNs for A, and they may not include all of its locators. Section 4., paragraph 11: > o In addition to failures detected based on end-to-end observations, > one endpoint might know for certain that one or more of its > locators is not working. For instance, the network interface > might have failed or gone down (at layer 2), or an IPv6 address > might have become deprecated or invalid. In such cases the host > can signal its peer that this address is no longer recommended to > try. This triggers something similar to a failure handling and a > new working locator pair must be found. From Bernard's tsv-dir review: In general, it would not be desirable for SHIM6 to initiate the re-homing of a TCP connection due to a transient failure. Link layer "down" indications or resulting address deprecations are examples of this. SCTP (RFC 4960) contains no equivalent advice. Section 5.12., paragraph 0: > 5.12. Keepalive Message Format > This message format is defined in [5]. From Bernard's tsv-dir review: Although I understand that the details of Keepalive algorithms might belong in a separate document, support for Keepalive appears to be required, so that the message format needs to be defined in the protocol document, and I would also like to see a discussion of the philosophy of Failure Detection in Section 1. Section 5.13., paragraph 0: > 5.13. Probe Message Format > This message and its semantics are defined in [5]. Similar to above, because this is required, the format should be defined here, and the basics of probing should be outlined. Section 8., paragraph 6: > But when the shim on the transmitting side inserts the payload > extension header and replaces the ULIDs in the IP address fields with > some other locators, then an ICMP error coming back will have a > "packet in error" which is not a packet that the ULP sent. Thus the > implementation will have to apply the reverse mapping to the "packet > in error" before passing the ICMP error up to the ULP. See > Figure 31. Please explicitly state that this translation process needs to correctly handle RFC4884 ICMP extensions. Since this is a recent PS, not all implementors may be aware of it. Section 15.3., paragraph 4: > o MTU implications. The path MTU mechanisms we use are robust > against different packets taking different paths through the > Internet, by computing a minimum over the recently observed path > MTUs. When Shim6 fails over from using one locator pair to > another pair, this means that packets might travel over a > different path through the Internet, hence the path MTU might be > quite different. Perhaps such a path change would be a good hint > to the path MTU mechanism to try a larger MTU? From Bernard's tsv-dir review: MTU discovery/MSS negotiation. This is briefly discussed in Section 15.3 of the protocol document. As noted there, SHIM6 failover may result in a change in MTU. Some specific recommendations might be helpful here (such as a recommendation to use Packetization Layer Path MTU discovery) Section 15.3., paragraph 5: > The fact that the shim will add an 8 octet Payload Extension > header to the ULP packets after a locator switch, can also affect > the usable path MTU for the ULPs. In this case the MTU change is > local to the sending host, thus conveying the change to the ULPs > is an implementation matter. From Bernard's tsv-dir review: The insertion of a Payload Extension (or common shim control message) header may also result in an MTU change in mid-connection; however, this seems easier to handle assuming that the transport layer is made aware of it and can reduce the MSS accordingly. Appendix A., paragraph 6: > o Potentially recommend that more application protocols use DNS SRV > records to allow a site some influence on load spreading for the > initial contact (before the Shim6 context establishment) as well > as for traffic which does not use the shim. From Bernard's tsv-dir review: Appendix A recognizes that DNS SRV RR usage is not common today and that changes to applications would be necessary to make full use of this feature. Is this really something that we want to recommend within the protocol document? |
2008-01-10
|
12 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2008-01-09
|
12 | Ross Callon | [Ballot discuss] Having thought about this, I think that the issue that I mentioned in a comment earlier really needs to be fixed, and thus … [Ballot discuss] Having thought about this, I think that the issue that I mentioned in a comment earlier really needs to be fixed, and thus raised to the level of a discuss. This refers to the third paragraph of section 3: The above scenario leads to the assumption that a host should be able to cause different egress paths from its site to be used. The most reasonable approach to accomplish this is to have the host use different source addresses and have the source address affect the selection of the site egress. The details of how this can be accomplished is beyond the scope of this document, but without this capability the ability of the shim to try different "paths" by trying different locator pairs will have limited utility. If shim6 depends upon source-and-destination based forwarding to be deployed in routers within each multi-homed site, then it is not likely to go anywhere (or at least this would be a significant barrier to deployment). However, I don't think that it needs source based routing. The normal operation of routing within a site should allow an egress that works to be selected for outgoing traffic. For example, in may cases a default route would be injected into the site for each CE router that has a link to a service provider. If one of the CE to PE links goes down, and the associated CE no longer has a link to a public service provider, than it can withdraw the default route that it injects to the site, causing outgoing traffic to choose a different egress point. Now, the failure of a CE to PE link, if it disconnects the site from a particular service provider, might mean that return traffic coming back to that site needs to use a different address for the destination address. If changing the source address on outgoing traffic causes the remote system to change the corresponding destination address on return traffic, then there might be some reason for a host to change the source address that it uses. Otherwise normal routing should find a workable egress point for traffic leaving this site, and the remote system will need to find an approprite destination address to use for traffic returning to the site. The authors, WG chairs, and/or shepherding AD should feel free to contact me if they need help in putting together appropriate text to correct this point. |
2008-01-09
|
12 | Cullen Jennings | [Ballot comment] I would have no problem with experimental. Many serious issues have been bought up in the discusses. It is not clear that these … [Ballot comment] I would have no problem with experimental. Many serious issues have been bought up in the discusses. It is not clear that these can all be fixed in any way where the protocol can still be useful in general circumstances. |
2008-01-09
|
12 | Ross Callon | [Ballot Position Update] New position, Discuss, has been recorded by Ross Callon |
2008-01-09
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Abstain from Undefined by Cullen Jennings |
2008-01-08
|
12 | Ron Bonica | [Ballot discuss] A side effect of shim6 is that it moves control wrt TE from the SP to the sending customer. This may or may … [Ballot discuss] A side effect of shim6 is that it moves control wrt TE from the SP to the sending customer. This may or may not be a good thing. Maybe we could add a small discussion of the pros and cons. |
2008-01-08
|
12 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica |
2008-01-02
|
12 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
2007-12-20
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings |
2007-12-20
|
12 | Jari Arkko | State Changes to IESG Evaluation - Defer from IESG Evaluation by Jari Arkko |
2007-12-20
|
12 | Magnus Westerlund | [Ballot comment] I definitely would like to see work continue on the notification between the shim and the transport protocol. This clearly is needed to … [Ballot comment] I definitely would like to see work continue on the notification between the shim and the transport protocol. This clearly is needed to ensure good performance and avoid some failure cases for the transport protocol. I also think the authors needs to address the Transport directorate review comments from Bernard Aboba. They need to be addressed and support holding a discuss based on it. |
2007-12-20
|
12 | Magnus Westerlund | [Ballot discuss] Section 8. To me it appears that not all type of ICMP error messages should be forward to the ULP. Instead the SHIM … [Ballot discuss] Section 8. To me it appears that not all type of ICMP error messages should be forward to the ULP. Instead the SHIM should intercept them and use them as a basis for a failover. I think some explicit consideration of the different types of ICMP errors and which should translated and which shouldn't. And if you have considered why also these two: 0 = net unreachable; 1 = host unreachable; shouldn't be used by SHIM6 rather than being forwarded please explain the reasoning. |
2007-12-20
|
12 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2007-12-20
|
12 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-12-20
|
12 | Chris Newman | [Ballot comment] Unfortunately, I came across this document too late to do the level of review necessary to verify it meets the goal "Have minimal … [Ballot comment] Unfortunately, I came across this document too late to do the level of review necessary to verify it meets the goal "Have minimal impact on upper layer protocols in general and on transport protocols and applications in particular" prior to the IESG call. My suspicion is it can not without suggesting an API for accessing endpoint IP addresses. My main concern with that claim is the level of transparency available to applications. Specifically, if this protocol is in use, then most applications need the ability to discover the set of valid interface addresses. While it is unusual for applications to actually transfer IP addresses across the wire, it is common practice for applications to make heavy use of IP addresses in server configuration and operation for functions such as inter-server access control, authorization, TLS session caching, connection throttling, DOS-protection, etc. |
2007-12-20
|
12 | Chris Newman | [Ballot Position Update] New position, Abstain, has been recorded by Chris Newman |
2007-12-20
|
12 | Ross Callon | [Ballot comment] Third paragraph of section 3: The above scenario leads to the assumption that a host should be able to cause different … [Ballot comment] Third paragraph of section 3: The above scenario leads to the assumption that a host should be able to cause different egress paths from its site to be used. The most reasonable approach to accomplish this is to have the host use different source addresses and have the source address affect the selection of the site egress. The details of how this can be accomplished is beyond the scope of this document, but without this capability the ability of the shim to try different "paths" by trying different locator pairs will have limited utility. I don't think that this (having source address effect egress selection) is really the best way to handle this scenario. If one of the addresses for a given site is not working, then one likely cause is that the connectivity from the site to the associated ISP is down. On egress, this might for example be better fixed by having the route that is being advertised into the site from that ISP (for example, possibly a default route advertised by a CE router into a site) no longer advertised, so that the outgoing packet from the site would go via a different egress. This implies that normal application of IP routing would solve the problem in the outgoing direction. It is the return direction that would need to be solved by selecting a different address (which might be a different source address for traffic from the site to elsewhere, but would turn into a different destination address for return traffic). |
2007-12-19
|
12 | David Ward | [Ballot discuss] 3. Assumptions The above scenario leads to the assumption that a host should be able to cause different egress paths from its … [Ballot discuss] 3. Assumptions The above scenario leads to the assumption that a host should be able to cause different egress paths from its site to be used. The most reasonable approach to accomplish this is to have the host use different source addresses and have the source address affect the selection of the site egress. The details of how this can be accomplished is beyond the scope of this document, but without this capability the ability of the shim to try different "paths" by trying different locator pairs will have limited utility. The opening assumption says that the resulting protocol will not be useful in real life. Fundamentally to make that work the local routers would have to do source based routing to avoid exiting into the wrong ISP ingress filter. 4. Protocol Overview The purpose of this heuristic is to avoid setting up a shim context when only a small number of packets is exchanged between two hosts. The follow-on assumption seems to say that the mechanism will never be used for the vast majority of the existing short-burst application traffic. I have no problem with publishing the set as Experimental, but any other status may be causing a lot of heartache for the authors. If this goes on standards track all of the firewalls would have to implement an undefined host-firewall signaling protocol, then the firewalls would have to implement a state transfer between all the site boundaries. All the intra-site routers would have to implement source prefix based routing to get the packet to its proper exist point. Then even if they did all that work, the number of flows where this would get used are very, very small. |
2007-12-19
|
12 | David Ward | [Ballot discuss] 3. Assumptions The above scenario leads to the assumption that a host should be able to cause different egress paths from its … [Ballot discuss] 3. Assumptions The above scenario leads to the assumption that a host should be able to cause different egress paths from its site to be used. The most reasonable approach to accomplish this is to have the host use different source addresses and have the source address affect the selection of the site egress. The details of how this can be accomplished is beyond the scope of this document, but without this capability the ability of the shim to try different "paths" by trying different locator pairs will have limited utility. The opening assumption says that the resulting protocol will not be useful in real life. Fundamentally to make that work the local routers would have to do source based routing to avoid exiting into the wrong ISP ingress filter. 4. Protocol Overview The purpose of this heuristic is to avoid setting up a shim context when only a small number of packets is exchanged between two hosts. The follow-on assumption seems to say that the mechanism will never be used for the vast majority of the existing short-burst application traffic. |
2007-12-19
|
12 | David Ward | [Ballot Position Update] New position, Discuss, has been recorded by David Ward |
2007-12-19
|
12 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Abstain from No Objection by Lisa Dusseault |
2007-12-19
|
12 | Lisa Dusseault | [Ballot comment] I appreciate the Assumptions section, but for this reader, it didn't go far enough. It's not clear up front how SHIM6 support is … [Ballot comment] I appreciate the Assumptions section, but for this reader, it didn't go far enough. It's not clear up front how SHIM6 support is advertised and discovered. It's not clear why a host that isn't multi-homed would support it. I don't understand if this has to be deployed across an entire site to be useful, or just one node can go SHIM6. It's not clear what intermediary support is required. |
2007-12-19
|
12 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault |
2007-12-19
|
12 | Tim Polk | [Ballot discuss] [This is a resend... I munged the cut-paste of Magnus' review] This is a placeholder DISCUSS for the issues raised in Magnus Nystrom's … [Ballot discuss] [This is a resend... I munged the cut-paste of Magnus' review] This is a placeholder DISCUSS for the issues raised in Magnus Nystrom's secdir review from December 10. I may add additional issues upon completion of my own review, but the key length and flooding attack points should. I have appended Magnus' review below: - Section 7.10.1, 2nd paragraph is confusing and needs to be re-written. - Section 7.20, last paragraph: "... the host updates the context information...The context state remains unchanged." This seems contradictory and it would be good with a clarification. Also, the English in this whole bullet (starting "If the state is ESTABLISHED ...") should be reviewed. Section 16, General: - Missing discussion around premeditated redirection attacks - It would be good to refer back to RFC 4218, i.e. to replicate the systematic treatment of threats in that RFC and explain how each threat is handled in Shim6. Section 16, Specific: - First bullet: "The minimum acceptable key length for public keys... SHOULD be 1024 bits" - Firstly, there is no identification of the key algorithm (RFC 3972 does not seem to require RSA). Secondly, the statement does not clarify what the minimum (absolute) requirement is. I would recommend MUST be at least 1024 and SHOULD be longer. - Both the first and second bullet text needs rewriting for clarity, e.g. for the second bullet to something like: "3rd party flooding attacks are prevented by requiring a Shim6 peer to perform a successful Reachability probe + reply exchange as defined in [5] before accepting a new locator for use as a packet destination." |
2007-12-19
|
12 | Tim Polk | [Ballot discuss] This is a placeholder DISCUSS for the issues raised in Magnus Nystrom's secdir review from December 10. I may add additional issues upon … [Ballot discuss] This is a placeholder DISCUSS for the issues raised in Magnus Nystrom's secdir review from December 10. I may add additional issues upon completion of my own review, but the key length and flooding attack points should. I have appended Magnus' review below: - Section 7.10.1, 2nd paragraph is confusing and needs to be re-written. - Section 7.20, last paragraph: "... the host updates the context information...The context state remains unchanged." This seems contradictory and it would be good with a clarification. Also, the English in this whole bullet (starting "If the state is ESTABLISHED ...") should be reviewed. General: - Missing discussion around premeditated redirection attacks - It would be good to refer back to RFC 4218, i.e. to replicate the systematic treatment of threats in that RFC and explain how each threat is handled in Shim6. Specific: - First bullet: "The minimum acceptable key length for public keys... SHOULD be 1024 bits" - Firstly, there is no identification of the key algorithm (RFC 3972 does not seem to require RSA). Secondly, the statement does not clarify what the minimum (absolute) requirement is. I would recommend MUST be at least 1024 and SHOULD be longer. - Both the first and second bullet text needs rewriting for clarity, e.g. for the second bullet to something like: "3rd party flooding attacks are prevented by requiring a Shim6 peer to perform a successful Reachability probe + reply exchange as defined in [5] before accepting a new locator for use as a packet destination." |
2007-12-19
|
12 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-12-19
|
12 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2007-12-19
|
12 | Dan Romascanu | [Ballot discuss] Part of the issues raised by this DISCUSS have been raised in the DNS-DIR review by Peter Koch. 1. This new protocol specification … [Ballot discuss] Part of the issues raised by this DISCUSS have been raised in the DNS-DIR review by Peter Koch. 1. This new protocol specification is missing any information concerning operational and manageability issues. I would have expected at least that section 15 Implications Elsewhere would include a subsection concerning the operational aspects related to the introduction of the protocol like impact on the traffic level, strategy of deployment, are configuration operations expected on hosts runing the protocol, etc. 2. The basic shim6 protocol specification mentions DNS SRV quite a lot (in section 5.15.3), but only to borrow priority/weight interaction definition. No DNS SRV RRs are involved explicitly, but the section 1.7 on traffic engineering reads: identical to the DNS SRV [6] specification of priority and weight, so that DNS SRV records can be used for initial contact and the shim for failover, and they can use the same way to describe the preferences. How would the SRV RR be used in this case? SRV is service specific, not to control preference levels for multiple addresses of the same host, primarily. 3. Appendix A also mentions the DNS SRV: o Potentially recommend that more application protocols use DNS SRV records to allow a site some influence on load spreading for the initial contact (before the Shim6 context establishment) as well as for traffic which does not use the shim. Shim use is already recommended against for name servers, but if a single host provides DNS and other services, conflicts might arise. For example, (some) name servers' addresses need to be stable for reasons of glue maintenance. This might encourage use of 'service based' IPv6 addresses. |
2007-12-19
|
12 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2007-12-19
|
12 | Sam Hartman | [Ballot discuss] Overall this is a well written document and I appreciate the work that has gone into it. First, I'm trying to figure out … [Ballot discuss] Overall this is a well written document and I appreciate the work that has gone into it. First, I'm trying to figure out if someone with HBA locators can use the update message to update their locator set. I am probably just missing it, but is there text in this spec (as apposed to the HBA spec) that requires if HBA verification is used, all the locators are HBAs? Presumably this requirement is intended to exist? Unfortunately, there is a significant conflict between this document and RFC 4301.This document has an architecture of the IP layer where there is a sub-layer responsible for routing and a sub-layer responsible for ULP interactions, fragmentation, etc. The shim is inserted between these two layers. The document assumes that IPsec processing happens in the layer that does fragmentation--above the shim. RFC 4301 also has a detailed architecture of IP and in particular IPsec processing. They aren't the same. RFC 4301 divides interfaces into protected and unprotected interfaces. IPsec processing and the SPD are consulted when a packet crosses from a protected interface to an unprotected interface. In the RFC 4301 model you need to understand what interface a packet will be routed out on before making a decision about IPsec processing. This is an important part of the IPsec model. I may have two paths out of my system. One over a trusted network and one over an untrusted network. If a link or path fails and the trusted network is no longer available IPsec processing may suddenly be required. However the reasoning in the shim6 draft about why you may want the shim below IPsec also applies in some configurations. What is clear to me is we have significantly more work to do on this issue. It is also clear that if shim6 is going to change the IPsec processing model, RFC 4301 must be updated either by this spec or by some document normatively referenced by this spec. Finally, shim6 may not change the IPsec processing model without involving the security community and getting appropriate review. |
2007-12-19
|
12 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-12-18
|
12 | Cullen Jennings | [Ballot comment] Treat these as late last call comments .... I think that the applicability statement is an important part of this standard and really … [Ballot comment] Treat these as late last call comments .... I think that the applicability statement is an important part of this standard and really should be normatively references or directly included in the main document. But if others disagree, I'm fine with it as it is. I hope the WG very quickly produces an API document that allows the upper levels to be notified of changes - most the important RAI applications I can think of would have weird failure cases if they were no API to do this and they wanted to use SHIM6. |
2007-12-18
|
12 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-12-17
|
12 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
2007-12-17
|
12 | Lars Eggert | [Ballot discuss] This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html (I may add … [Ballot discuss] This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html (I may add to this DISCUSS based on my own IESG review.) |
2007-12-17
|
12 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2007-12-11
|
12 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom. |
2007-11-27
|
12 | Jari Arkko | Placed on agenda for telechat - 2007-12-13 by Jari Arkko |
2007-11-23
|
12 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2007-11-23
|
12 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2007-11-23
|
12 | Jari Arkko | Ballot has been issued by Jari Arkko |
2007-11-23
|
12 | Jari Arkko | Created "Approve" ballot |
2007-11-22
|
12 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-11-20
|
12 | Amanda Baber | IANA Last Call comments: IANA has questions. Action #1: Upon approval of this document, the IANA will assign an IP Protocol Number for Shim6. **QUESTION: … IANA Last Call comments: IANA has questions. Action #1: Upon approval of this document, the IANA will assign an IP Protocol Number for Shim6. **QUESTION: In which registry should this assignment be made? Possibilities appear to include http://www.iana.org/assignments/version-numbers http://www.iana.org/assignments/ipv6-parameters, sub-registry 5.a http://www.iana.org/assignments/ip-parameters Action #2: Upon approval of this document, the IANA will make the following assignment in the "CGA Message Type Name Space" registry at http://www.iana.org/assignments/cga-message-types sub-registry "CGA Extension Type Tags" Registry: CGA Type Tag Reference ---------------------------------------------+----------- 0x4A30 5662 4858 574B 3655 416F 506A 6D48. | [RFC-shim6-proto-09] Action #3 Upon approval of this document, the IANA will create a registry called "Shim6 Parameters," to be located at http://www.iana.org/assignments/TBD Initial contents are defined in Actions 4-6. Action #4 Upon approval of this document, the IANA will create a sub-registry called "Sim6 Types" in "Shim6 Parameters." Registration Procedure: Standards Action Initial contents of this sub-registry will be: Type Value | Message | Reference ------------+-----------------------------------------------------+----------- + 0 | RESERVED |[RFC-shim6-proto-09] | | 1 | I1 (first establishment message from the initiator) |[RFC-shim6-proto-09] | | 2 | R1 (first establishment message from the responder) |[RFC-shim6-proto-09] | | 3 | I2 (2nd establishment message from the initiator) |[RFC-shim6-proto-09] | | 4 | R2 (2nd establishment message from the responder) |[RFC-shim6-proto-09] | | 5 | R1bis (Reply to reference to non-existent context) |[RFC-shim6-proto-09] | | 6 | I2bis (Reply to a R1bis message) |[RFC-shim6-proto-09] | | 7-59 | Can be allocated using Standards Action |[RFC-shim6-proto-09] | | 60-63 | For Experimental use |[RFC-shim6-proto-09] | | 64 | Update Request |[RFC-shim6-proto-09] | | 65 | Update Acknowledgement |[RFC-shim6-proto-09] | | 66 | Keepalive |[RFC-shim6-proto-09] | | 67 | Probe Message |[RFC-shim6-proto-09] | | 68 | Error Message |[RFC-shim6-proto-09] | | 69-123 | Can be allocated using Standards Action |[RFC-shim6-proto-09] | | 124-127 | For Experimental use |[RFC-shim6-proto-09] **QUESTION: Type 68 was listed in section 5.3, but not in the IANA Considerations. Should this type be assigned? Action #5 Upon approval of this document, the IANA will create a sub-registry called "Sim6 Options" in "Shim6 Parameters." Registration Procedure: Standards Action Initial contents of this sub-registry will be: | Type | Option Name | +-------------+----------------------------------+------------------- | 0 | RESERVED | [RFC-shim6-proto-09] | | | | 1 | Responder Validator | [RFC-shim6-proto-09] | | | | 2 | Locator List | [RFC-shim6-proto-09] | | | | 3 | Locator Preferences | [RFC-shim6-proto-09] | | | | 4 | CGA Parameter Data Structure | [RFC-shim6-proto-09] | | | | 5 | CGA Signature | [RFC-shim6-proto-09] | | | | 6 | ULID Pair | [RFC-shim6-proto-09] | | | | 7 | Forked Instance Identifier | [RFC-shim6-proto-09] | | | | 8-9 | Allocated using Standards action | [RFC-shim6-proto-09] | | | | 10 | Keepalive Timeout Option | [RFC-shim6-proto-09] | | | | 11-16383 | Allocated using Standards action | [RFC-shim6-proto-09] | | | | 16384-32767 | For Experimental use | [RFC-shim6-proto-09] Action #6 Upon approval of this document, the IANA will create a sub- registry called "Sim6 Error Messages" in "Shim6 Parameters." Initial contents of this sub-registry will be: | Code Value | Description | +------------+--------------------------------------------+---------------- --- | 0 | Unknown Shim6 message type | [RFC-shim6-proto-09] | | | | 1 | Critical Option not recognized | [RFC-shim6-proto-09] | | | | 2 | Locator verification method failed | [RFC-shim6-proto-09] | | | | 3 | Locator List Generation number out of sync | [RFC-shim6-proto-09] | | | | 4 | Error in the number of locators | [RFC-shim6-proto-09] | | | | 120-127 | Reserved for debugging pruposes | [RFC-shim6-proto-09] **QUESTION: Are values 5-119 available for allocation? If so, are they allocated by Standards Action, or according to another policy? We understand the above to be the only IANA Actions for this document. |
2007-11-09
|
12 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2007-11-09
|
12 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2007-11-08
|
12 | Amy Vezza | Last call sent |
2007-11-08
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-11-08
|
12 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2007-11-08
|
12 | Jari Arkko | Last Call was requested by Jari Arkko |
2007-11-08
|
12 | (System) | Ballot writeup text was added |
2007-11-08
|
12 | (System) | Last call text was added |
2007-11-08
|
12 | (System) | Ballot approval text was added |
2007-11-08
|
12 | Jari Arkko | A second AD reveals that all issues have been addressed or adequately explained. |
2007-11-01
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-11-01
|
09 | (System) | New version available: draft-ietf-shim6-proto-09.txt |
2007-09-13
|
12 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2007-09-13
|
12 | Jari Arkko | Last piece of AD review (appendixes skipped though): Continuing with the review. This goes right to the end, and I have set the state of … Last piece of AD review (appendixes skipped though): Continuing with the review. This goes right to the end, and I have set the state of the document to Revised ID Needed. I will still send some summary conclusions after thinking about the results of the review. But overall I'm relatively happy, almost everything that I found was just minor issues. Its a tough document to read given its size, but very well written and there was a very small number of obvious problems. Substantial: > > The Shim6 sub-layer is implemented below the IPSec layer within the > > IP layer. This deserves some additional considerations for a couple > > of specific cases: First, it should be noted that the Shim6 approach > > does not preclude using IPSEC tunnels on Shim6 packets within the > > network transit path. Second, in case that IPSec is implemented as > > Bump-In-The-Wire (BITW) [7], either the shim MUST be disabled, or the > > shim MUST also be implemented as Bump-In-The-Wire, in order to > > satisfy the requirement that IPsec is layered above the shim. Presumably the BITW implementation could also itself filter out Shim6 control packets, in which case the shim is never turned on. > > o An attacker which is present on the path so that it can find out > > the context tags, can generate a R1bis message after it has moved > > off the path. For this packet to be effective it needs to have a > > source locator which belongs to the context, Really? What if CGA is used, must the R1bis even then come from a previously known address? Editorial: > > In this case, it reccomended that the ... > > Shim6 follows the reccomendation defined in [28] and it informs the Typos. > > in order to allow the congestion > > control mechanisms of the upper layers can react accordingly. s/can/to/ > > The Shim6 sub-layer is implemented below the IPSec layer within the > > IP layer. This deserves some additional considerations for a couple > > of specific cases: First, it should be noted that the Shim6 approach > > does not preclude using IPSEC tunnels on Shim6 packets within the Different capitalizations of IPsec, none correct. |
2007-09-13
|
12 | Jari Arkko | Still continuing with the review. Sigh, its a long document... I also noticed a few things that forced me to go back in the document, … Still continuing with the review. Sigh, its a long document... I also noticed a few things that forced me to go back in the document, so don't be surprised about Section numbers below 7.18. Substantial: (From Section 5.10) > > CGA Parameter Data Structure (PDS): Included when the locator list > > is included and the PDS was not included in the I2/ > > I2bis/R2 messages, so the receiver can verify the > > locator list. (From Section 7.10) > > In > > particular, the R2 message includes the Responder's locator list and > > the PDS option. (From Section 7.16) > > If a CGA Parameter Data Structure (PDS) is > > included in the message, then the host MUST verify that the actual > > PDS contained in the message corresponds to the ULID(peer) as > > specified in Section 7.2. I am getting confused about when the PDS appears in the message when not. 7.10 seems to say its always there; 7.16 allows it to not be there; 5.10 explains some of the thinking. I think we need to be consistent with these recommendations, perhaps fixing Section 7.10 language. Same with Section 7.11 (sending I2) vs. Section 7.13 (receiving I2). And 7.14 vs. 7.16 (for R2). > > 7.18. Receiving R1bis messages and sending I2bis messages > > (nothing about PDS) > > ... > > 7.20. Receiving I2bis messages and sending R2 messages > > ... > > If a CGA Parameter Data Structure (PDS) is included in the message, > > then the host MUST verify if the actual PDS contained in the message > > corresponds to the ULID(peer). Inconsistent here, too. > > 10.1. Sending Update Request messages > > > > > > When a host has a change in the locator set, then it can communicate > > this to the peer by sending an Update Request. When a host has a > > change in the preferences for its locator set, it can also > > communicate this to the peer. 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. > > > > ... > > > > 10.4. Receiving Update Request messages > > > > ... > > If a CGA Parameter Data Structure (PDS) is included in the message, > > then the host MUST verify if the actual PDS contained in the packet > > corresponds to the ULID(peer). If this verification fails, the > > message is silently discarded. Again, the text about sending the Update does not talk about the PDS, while the receiving side does. This needs to be consistent. > > CGA Parameter Data Structure: Included when the locator list is > > included so the receiver can verify the locator list. There should be some discussion in the introductory parts of the document about the (non-)requirements to use HBA/CGA addresses on both sides. My understanding is that its OK for my multihomed host to have such addresses and that Shim6 still works with a host on the other side that only has one address. Right? > > A shim control message has the checksum field verified. The Shim > > header length field is also verified against the length of the IPv6 > > packet to make sure that the shim message doesn't claim to end past > > the end of the IPv6 packet. Finally, it checks that the neither the > > IPv6 destination field nor the IPv6 source field is a multicast > > address. If any of those checks fail, the packet is silently > > dropped. Are multicast addresses only ones that need to be prohibited? What about unspecified, link local unicast? Section 10: > > If a CGA Parameter Data Structure (PDS) is included in the message, > > then the host MUST verify if the actual PDS contained in the packet > > corresponds to the ULID(peer). If this verification fails, the > > message is silently discarded. This is probably explained in more detail elsewhere, but the above statement "correspond to the ULID(peer)" seems incorrect. Lets assume we have locators L1, L2, L3, L4. Lets further assume that ULID=L4. Now, we indeed need to verify that, e.g., the HBA equations prove L1, L2, L3, and L4 are related. I guess this can be stated as "PDS corresponds to the ULID(peer)". But how does this work for CGAs? Lets assume for the sake of argument that the CGA address = L1 and ULID is still L4. This seems possible, but it no longer holds that "PDS corresponds to ULID(peer)". Instead, you need to show one of the two: each address in the list is either hash(key) or the key has been used to sign the entire Update message, showing willingness of the key owner to use these other addresses. Reformulation of this text is probably needed. It appears in multiple places in the document, so make sure you fix all places. > > The host uses the Probe message in [9] to verify > > that the new locator is reachable before changing Lp(peer). The host uses the specific message, or runs the entire protocol? If the former, please specify in more detail the contents of the message. > > o Other control messages (Update, Keepalive, Probe): Deliver to the > > context with CT(local) equal to the Receiver Context Tag included > > in the packet. Verify that the IPv6 source address field is part > > of Ls(peer) and that the IPv6 destination address field is part of > > Ls(local). If not, send a R1bis message. Does this prevent properly handling a Probe if the peer did not bother to / did not have time to report the address as its own? I would expect that hosts might not report all addresses, if they have many, and if there's a sudden rehoming to a previously unknown prefix, the host HAS to send a Probe from this previously unknown address. This appears OK from a security perspective, at least if we are using CGAs and not HBAs. |
2007-09-13
|
12 | Jari Arkko | Continuing with the review, Sections 6 - 7.17: Substantial: > > o For each peer locator, a flag whether it has been verified using … Continuing with the review, Sections 6 - 7.17: Substantial: > > o For each peer locator, a flag whether it has been verified using > > HBA or CGA, and a bit whether the locator has been probed to > > verify that the ULID is present at that location. Is there a need to remember *when* such probing has last happened? If not, why not? > > o The preferred peer locator - used as destination; Lp(peer) First, this sentence was hard to parse. Second, preferred != the one we are using as a destination. Please explain or modify. Did you mean the current locator that we are using? The failure-detection draft uses the term "current address pair", so it would be good to align with that. I'm reading on... > > o The preferred local locator - used as source; Lp(local) As above. |
2007-09-13
|
12 | Jari Arkko | Continuing with the review, Section 5: Substantial: > > o For each peer locator, a flag whether it has been verified using > > … Continuing with the review, Section 5: Substantial: > > o For each peer locator, a flag whether it has been verified using > > HBA or CGA, and a bit whether the locator has been probed to > > verify that the ULID is present at that location. Is there a need to remember *when* such probing has last happened? If not, why not? > > o The preferred peer locator - used as destination; Lp(peer) First, this sentence was hard to parse. Second, preferred != the one we are using as a destination. Please explain or modify. Did you mean the current locator that we are using? The failure-detection draft uses the term "current address pair", so it would be good to align with that. I'm reading on... > > o The preferred local locator - used as source; Lp(local) As above. |
2007-09-11
|
12 | Jari Arkko | Continuing with the review: Substantial: > The following options are defined for this message: > > Responder Validator: Variable length option. Typically a … Continuing with the review: Substantial: > The following options are defined for this message: > > Responder Validator: Variable length option. Typically a hash > generated by the responder, which the responder uses > together with the Responder Nonce value to verify that > an I2 message is indeed sent in response to a R1 > message, and that the parameters in the I2 message are > the same as those in the I1 message. (Appears in multiple places in the document). Is the use of this option mandatory? What about its copying on the other side, if it is present? Please clarify. > Locator List Generation: 32-bit unsigned integer. Indicates a > generation number which is increased by one for each > new locator list. This is used to ensure that the > index in the Locator Preferences refer to the right > version of the locator list. Are there requirements on keeping this generation counter unique across reboots, or would rolling back not cause a problem? Is there a window that one should be following? Are generation counters unique per context tag? > +-------+----------+ > | Value | Method | > +-------+----------+ > | 0 | Reserved | > | | | > | 1 | HBA | > | | | > | 2 | CGA | > | | | > | 3-255 | Reserved | > +-------+----------+ I'm reading on, but what if it is the kind of a combined HBA and CGA as described in the shim6-hba draft? Presumably you indicate HBA if the locator is in the fixed set and CGA if its in the dynamic, but it would be good to clarify this. > This option contains the CGA Parameter Data Structure (PDS). When > HBA is used to verify the locators, the PDS contains the HBA > multiprefix extension. When CGA is used to verify the locators, in > addition to the PDS option, the host also needs to include the > signature in the form of a CGA Signature option. The Parameter Data Structure contains more than the multiprefix extension, e.g., the public key, the random bits instead of a public key for HBAs, and any options unrelated to Shim6 that the CGA might have. I would remove the second sentence above or reword it to make sure that you really do include the FULL CGA Parameter Data Structure. Editorial: > included, the packet would become larger than 1280 bytes.Another s/[.]/. / > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Hdr Ext Len |0| Type |Type-specific|0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Type-specific format | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Fields: > > Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59). > > Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in > 8-octet units, not including the first 8 octets. > > P: Set to zero. A single bit to distinguish this from > the Shim6 payload extension header. > > Type: 7-bit unsigned integer. Identifies the actual message > from the table below. Type codes 0-63 will not > trigger R1bis messages on a missing context, while 64- > 127 will trigger R1bis. > > 0: A single bit (set to zero) which allows Shim6 and HIP > to have a common header format yet telling Shim6 and > HIP messages apart. Here I got confused about the two 0's. The first one is P in the list, the other one is "0". Maybe you need to set one of the zeroes in the picture to something else (P or R), or add some text to make this clearer. |
2007-09-10
|
12 | Jari Arkko | I have started my AD review of this document. Please find comments relating to Sections 1 through 4 below, along with some tool-generated editorial issues. … I have started my AD review of this document. Please find comments relating to Sections 1 through 4 below, along with some tool-generated editorial issues. Substantial: Generally speaking I'm happy with the parts that I have read so far. The text is easy to read and the reader gets an accurate understanding of the Shim6 protocol, its capabilities and limitations. The only substantial question mark that I had was here: > > However, the precise > > interaction between Mobile IPv6 and Shim6 is for further study, but > > it might make sense to have Mobile IPv6 operate on locators as well, > > meaning that the shim would be layered on top of the MIPv6 mechanism. > > I worry that there's a circular dependency somewhere between IPsec, Shim6, and MIPv6 if they all require something about the placement of other layers on top or under them. Or is Shim6 capable to be configured to run in different places in the stack, e.g., inside and outside a tunnel, depending on what the network manager wants? This may be explained somewhere else... Editorial: > > Figure 31: ICMP error handling with payload extension header Extra space. > > == Unused Reference: '4' is defined on line 5394, but no explicit reference > > was found in the text > > > > == Unused Reference: '5' is defined on line 5397, but no explicit reference > > was found in the text > > > > == Unused Reference: '12' is defined on line 5425, but no explicit > > reference was found in the text > > > > == Unused Reference: '24' is defined on line 5464, but no explicit > > reference was found in the text > > > > == Unused Reference: '25' is defined on line 5469, but no explicit > > reference was found in the text > > > > == Unused Reference: '27' is defined on line 5476, but no explicit > > reference was found in the text Please add references or remove the documents. > > ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) > > > > == Outdated reference: A later version (-03) exists of > > draft-ietf-shim6-hba-02 > > > > == Outdated reference: A later version (-08) exists of > > draft-ietf-shim6-failure-detection-07 > > > > == Outdated reference: A later version (-03) exists of > > draft-ietf-shim6-applicability-02 > > > > == Outdated reference: A later version (-08) exists of > > draft-ietf-hip-base-07 > > > > == Outdated reference: draft-ietf-mobike-protocol has been published as RFC > > 4555 > > Please use the updated references. > > was computed. See [6]., [8]. Extra "." > > A, B, and C are hosts. X is a potentially malicious host. > > > > ... > > > > CT(X) is a context tag assigned by X. Wouldn't CT(A) be a more appropriate notation? Or are you specifically saying that its the malicious host? |
2007-08-31
|
12 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2007-08-22
|
12 | Jari Arkko | [Note]: 'Please also read draft-ietf-shim6-applicability Document Shepherd is Geoff Huston <gih@apnic.net>' added by Jari Arkko |
2007-08-17
|
12 | Jari Arkko | [Note]: 'Document Shepherd is Geoff Huston <gih@apnic.net>' added by Jari Arkko |
2007-08-17
|
12 | Jari Arkko | (1.a) Who is the Document Shepherd for this document? Geoff Huston … (1.a) Who is the Document Shepherd for this document? Geoff Huston Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes (1.b) Has the document had adequate review both from key members of the interested community and others? Yes, the document has been explicitly called to the attention of the Working Group on a number of occasions, and review comments have been incorporated into the document. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd is comfortable with the level of review of this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document has been reviewed extensively over the past 15 months and the Document Shepherd is comfortable with the competence and breadth of review of this document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I do not have specific concerns, but I would like to highlight a number of matters that have arisen in the Working Group and elsewhere relating to SHIM6, and the manner of their resolution in this protocol specification. The document has attracted comment over middleware checking the integrity of the TCP header checksum. The Working Group consensus was to recommend that middleware behaviour take into account the presence of a shim6 payload header and modify their behaviour accordingly. It was not established to what extent this is an issue. Other alternatives relating to detection of middleware that performs TCP/UDP checksum validation and additional flags in the chim6 payload header were canvassed by the Working Group, but recieved no clear support. Working Group review noted that Bump-In-The-Wire (BITW) IPSEC is incompatible with the default placement of the shim6 element in the packet processing path. The Working Group position is that in the case of BITW IPSEC it is mandated that shim6 must either be disabled or implemented using the same BITW approach to preserve the logival ordering of placing IPSEC processing immediately "above" SHIM6 in the logical protocol stack flow. Review of SHIM6 in other forums, noteably in the NANOG forum has attracted the comment that there is no mechanism in SHIM6 for site-based control, and placing this functionality in end hosts rather than site edges was considered to be a sub-optimal approach. The response to this is 2-fold: firstly the SHIM6 WG is not chartered to develop a generic architecture for multi-homing, but to work specifically on the architecure developed by the Multi6 Working Group. Secondly, the Working Group has informally explored extensions to the shim6 approach that may include interaction with site edge routers, but at this stage the Working Group sees this initial approach as being within its charter, and that re-chartering the Working Group to explore such extenxions may be appropriate once this initial "base" specification of the shim6 approach has been completed. A similar approach of deferring working on extensions to SHIM6 until the completion of this "base" specification also applies to the consideration raised about interaction between upper level protocol behaviour and SHIM6. The base specification has the capability for context forking for individual connections in order to permit individual connections to function with different preferences for locator pairs. The manner of interaction between the upper level protocol and SHIM6 is regarded as an extension to the "base" specification. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? The document has been reviewed from a range of perspectives and has generated review comment from these perspectives. The consensus behind this document appears to be well-founded. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes Reference [5] (RFC2463) now refers to an obsoleted spec - it should be replaced with a reference to RFC4443 The update to this document can be undertaken in the form of a note to the RFC Editor. There are a number of document typos. The list is: page 14: s"[6]."[6]" page 24: s"bytes.Another"bytes. Another" page 40: s"field.Identifies"field. Identifies" page 41: s"pruposes"purposes" page 54: s"unstrucutred "unstructured" page 64: s"recieve"receive" page 70: s"The the"The" page 72: s"The the"The" page 82: s"extenson"extension" page 82: s"porpuses"purposes" page 88: s"reccomended"recommended" page 88: s"reccomendation"recommendation" page 88: s"presudoheader"pseudoheader" page 88: s"header header"header" page 92: s"the the"the" page 94: s"[CGA] namespace registry"CGA Extension Type Values registry" page 95: s"pruposes"purposes" page 105: s"Tiemout"Timeout" page 105: s"Tiemout"Timeout" page 121: s"crtical"critical" page 121: s"estbalishment"establishment" page 121: s"recgnized"recognized" page 121: s"strcuture"structure" page 121: s"commnets"comments" page 121: s"reccomendation"recommendation" page 122: s"meesages"messages" page 122: s"retransmision"retransmission" page 122: s"respon der"responder" page 122: s"renumberin"renumbering" page 122: s"synchonized"synchronized" Additional changes to refer to related shim6 documents in an informative manner have been proposed in the form of an RFC Editor Note: Add the paragraph at the end of section 1 (and immediately before section 1.1) "The applicability of the Shim6 protocol is considered in [24]. The architecture of this approach is described in [25]." (1.h) Has the document split its references into normative and informative? Yes Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No If such normative references exist, what is the strategy for their completion? Reference [8] is being submitted to the IESG for publication with this document. Reference [9] is being submitted to the IESG for publication with this document. Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Yes Are the IANA registries clearly identified? Yes If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Yes Future registrations are allocated via "Standards Action" ** Code values 5 through 119 of the Shim6 Error Code registry are undefined. It is suggested that the following additon be made to the document on page 95: 5 - 119 Allocated using Standards action Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. Yes If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines the Shim6 protocol, a layer 3 shim for IPv6 that provides locator agility below the transport protocols. Shim6 provides IPv6 hosts in a multihomed site 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. Shim6-enabled hosts in a multihomed site will use the Shim6 protocol specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original pair stop working, while preserving the integrity of active transport layer sessions. Working Group Summary The document has extensively reviewed by the Working Group. The Working Group consensus was to recommend publication of this document as a Proposed Standard. Document Quality There are known implementations of this specification, and there have been no implementation experiences that have implied any further revision to this specification is required. Additional note: The document is being passed to the IESG as part of a set of three documents that the Working Group has determined by consensus in the WG Last Calls has requested to be published as Proposed Standards. The Document Shepherd is aware that there have been suggestions to publish initially as Experimental, and notes that the Working Group Last Call specifically noted the intended request to publish as a Proposed Standard, and this request is based on that Working Group consensus position. The specification meets all the criteria of section 4.1.1 of RFC 2026, in that the specification is stable, has resolved design choices, is believed to be well understood and has received considerable community interest. The specification has no known technical omissions. In addition, there are a number of implementations of the specification, but little in the way of operational experience, interoperability between implementations and interaction with application behavior to report on at this stage. |
2007-07-10
|
12 | Jari Arkko | waiting for text from the chairs to fix Brian Carpenter's WGLC issue about SCTP bypass |
2007-07-10
|
12 | Jari Arkko | State Changes to Publication Requested from AD is watching by Jari Arkko |
2007-07-10
|
12 | Jari Arkko | Waiting for document writeup from chairs |
2007-07-10
|
12 | Jari Arkko | Responsible AD has been changed to Jari Arkko from Mark Townsley |
2007-07-10
|
12 | Jari Arkko | State Change Notice email list have been change to shim6-chairs@tools.ietf.org,draft-ietf-shim6-proto@tools.ietf.org from shim6-chairs@tools.ietf.org |
2007-07-10
|
12 | Jari Arkko | Intended Status has been changed to Proposed Standard from None |
2007-04-23
|
08 | (System) | New version available: draft-ietf-shim6-proto-08.txt |
2006-12-06
|
07 | (System) | New version available: draft-ietf-shim6-proto-07.txt |
2006-10-25
|
06 | (System) | New version available: draft-ietf-shim6-proto-06.txt |
2006-10-19
|
12 | Mark Townsley | Draft Added by Mark Townsley in state AD is watching |
2006-05-25
|
05 | (System) | New version available: draft-ietf-shim6-proto-05.txt |
2006-03-07
|
04 | (System) | New version available: draft-ietf-shim6-proto-04.txt |
2005-12-21
|
03 | (System) | New version available: draft-ietf-shim6-proto-03.txt |
2005-10-27
|
02 | (System) | New version available: draft-ietf-shim6-proto-02.txt |
2005-10-12
|
01 | (System) | New version available: draft-ietf-shim6-proto-01.txt |
2005-10-03
|
00 | (System) | New version available: draft-ietf-shim6-proto-00.txt |