IEEE 802.21 Mobility Services Framework Design (MSFD)
draft-ietf-mipshop-mstp-solution-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the Abstain position for Pasi Eronen |
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 Russ Housley |
2009-02-06
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-02-06
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-02-06
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-02-05
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-02-05
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-02-05
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-02-04
|
12 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2009-02-04
|
12 | (System) | IANA Action state changed to In Progress |
2009-02-04
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-02-04
|
12 | Amy Vezza | IESG has approved the document |
2009-02-04
|
12 | Amy Vezza | Closed "Approve" ballot |
2009-02-04
|
12 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko |
2009-02-03
|
12 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to Abstain from Discuss by Pasi Eronen |
2009-02-03
|
12 | Pasi Eronen | [Ballot comment] Two of the four scenarios (described in Section 3) talk about running this protocol across multiple administrative domains, possibly even over the general … [Ballot comment] Two of the four scenarios (described in Section 3) talk about running this protocol across multiple administrative domains, possibly even over the general Internet. I don't think leaving how to use this securely for future work (or proprietary solutions) is OK in a Standards Track RFC, and does not meet the requirements of BCP61. Realistically, this draft cannot fix the situation, so I proposed publishing this as Experimental instead (with strongly worded IESG note). While there can be valid reasons to grant exceptions to BCP61, in my opinion "some folks prefer to do protocols first and think about security later" is one of them, even when "some folks" come from another SDO. However, apparently other ADs don't share my opinion here, so I'm balloting "Abstain". |
2009-02-03
|
12 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2009-02-03
|
12 | Jari Arkko | Waiting on authors, 802.21 chairs, and Pasi. |
2009-01-30
|
12 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-01-30
|
12 | (System) | New version available: draft-ietf-mipshop-mstp-solution-12.txt |
2009-01-30
|
12 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Amy Vezza |
2009-01-30
|
12 | (System) | Removed from agenda for telechat - 2009-01-29 |
2009-01-29
|
12 | Pasi Eronen | [Ballot discuss] Two of the four scenarios (described in Section 3) talk about running this protocol across multiple administrative domains, possibly even over the general … [Ballot discuss] Two of the four scenarios (described in Section 3) talk about running this protocol across multiple administrative domains, possibly even over the general Internet. I don't think leaving how to use this securely for future work (or proprietary solutions) is OK in a Standards Track RFC, and does not meet the requirements of BCP61. Realistically, this draft cannot fix the situation, so I propose publishing this as Experimental instead (with strongly worded IESG note). While there can be valid reasons to grant exceptions to BCP61, I do not think "some folks prefer to do protocols first and think about security later" is one of them, even when "some folks" come from another SDO. However, if other ADs do not share my opinion, I am willing to move to "Abstain". |
2009-01-28
|
12 | Cullen Jennings | [Ballot comment] Support PASI discuss. |
2009-01-28
|
12 | Russ Housley | [Ballot comment] |
2009-01-28
|
12 | Russ Housley | [Ballot discuss] The Gen-ART Review by David Black was posted on 27-Jan-2009, and Jari has indicated that the concerns raised ought to be addressed. … [Ballot discuss] The Gen-ART Review by David Black was posted on 27-Jan-2009, and Jari has indicated that the concerns raised ought to be addressed. Please update the document or provide RFC Editor notes. |
2009-01-28
|
12 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from No Objection by Russ Housley |
2009-01-28
|
12 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2009-01-28
|
12 | Jari Arkko | Waiting for authors and Pasi to agree that my IESG note is OK. |
2009-01-15
|
12 | Cindy Morgan | Placed on agenda for telechat - 2009-01-29 by Cindy Morgan |
2009-01-15
|
12 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2009-01-15
|
12 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2009-01-15
|
12 | Pasi Eronen | [Ballot discuss] The document says: "This document does not provide mechanisms for securing the communication between a mobile node and the mobility service. Instead, it … [Ballot discuss] The document says: "This document does not provide mechanisms for securing the communication between a mobile node and the mobility service. Instead, it is assumed that either lower layer (e.g., link layer) security mechanisms, or overall system-specific proprietary security solutions, are used. The details of such lower layer and/or proprietary mechanisms are beyond the scope of this document." I don't think leaving how to use this securely for future work (or proprietary solutions) is OK in a Standards Track RFC. Realistically, this draft cannot fix the situation, so I propose publishing this as Experimental instead. |
2009-01-14
|
12 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-01-14
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-01-14
|
11 | (System) | New version available: draft-ietf-mipshop-mstp-solution-11.txt |
2009-01-13
|
12 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2009-01-13
|
12 | Jari Arkko | Placed on agenda for telechat - 2009-01-15 by Jari Arkko |
2009-01-13
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-01-13
|
10 | (System) | New version available: draft-ietf-mipshop-mstp-solution-10.txt |
2008-11-04
|
12 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2008-11-04
|
12 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2008-11-04
|
12 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2008-11-04
|
12 | Jari Arkko | Putting doc in revised id needed for Pasi's discuss. |
2008-11-04
|
12 | Jari Arkko | Cullen's discuss seems to be addressed in -09. Asking Lars about his. Its more of a borderline case maybe. |
2008-11-04
|
12 | Magnus Westerlund | [Ballot comment] |
2008-11-04
|
12 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-11-03
|
09 | (System) | New version available: draft-ietf-mipshop-mstp-solution-09.txt |
2008-10-19
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-10-19
|
08 | (System) | New version available: draft-ietf-mipshop-mstp-solution-08.txt |
2008-10-16
|
12 | Chris Newman | [Ballot comment] I support Pasi's discuss. TLS has shown to be a deployable privacy solution in the real world. In addition to privacy, it includes … [Ballot comment] I support Pasi's discuss. TLS has shown to be a deployable privacy solution in the real world. In addition to privacy, it includes authentication support that works in some scenarios or when combined with SASL/EAP/HTTP-auth or some other authentication framework), but it has lots of knobs that have to be specified when a protocol chooses to use it. We've had some mistakes when binding it to application protocols that caused real deployment problems and had to be corrected (the most notable is allowing "STARTTLS" to be advertised as a capability by a server even if no server certificate is installed). I strongly recommend getting this right early rather than botching it and having to work around bad deployment practices. |
2008-09-25
|
12 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2008-09-25
|
12 | Tim Polk | [Ballot comment] [I have cleared my discuss and moved this to a comment after discussion with the sponsoring AD...] Section 5 puts a lot of … [Ballot comment] [I have cleared my discuss and moved this to a comment after discussion with the sponsoring AD...] Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?) Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MIH message Size in 6.1 and rate in 6.2) ? |
2008-09-25
|
12 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2008-09-25
|
12 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2008-09-25
|
12 | Tim Polk | [Ballot comment] [I have cleared my discuss and moved this toa comment after discussion with the sponsoring AD...] Section 5 puts a lot of effort … [Ballot comment] [I have cleared my discuss and moved this toa comment after discussion with the sponsoring AD...] Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?) Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MIH message Size in 6.1 and rate in 6.2) ? |
2008-09-25
|
12 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2008-09-25
|
12 | David Ward | [Ballot comment] I will let the others hold the discuss but, they must be cleared. |
2008-09-25
|
12 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-09-25
|
12 | Pasi Eronen | [Ballot discuss] (Updated discuss) I have read draft-ietf-mipshop-mstp-solution-06. It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't … [Ballot discuss] (Updated discuss) I have read draft-ietf-mipshop-mstp-solution-06. It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't read), but I have the following concerns that I'd like to discuss: The document currently says that TLS can be used, but is silent about the details. For example, how authentication and authorization are done -- e.g. are some fields in certificates expected to match some fields in the MIH protocol? What the certificates are expected to look like? How this interacts with the discovery mechanisms (e.g. NAPTR specs recommend that the certificate contains the *input* to NAPTR processing, not the output -- but some specs have chosen otherwise)? What the mandatory-to-implement parts of TLS are? In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem inconsistent (MoSV is defined as "anything that isn't a MoSh", and MoS3 is defined as "anything that isn't a MoSh or MoSV" -- but that would seem to make MoS3 an empty set). The document assumes that NAI can be used to identify a MIHF endpoint; but usually NAI identifies a user account which can be used simultaneously on multiple hosts (each of which would be a separate MIHF endpoint). It seems that both MIH-over-TLS-over-TCP and MIH-over-TCP use the same port number (likewise for DTLS/UDP case) -- how does the recipient distinguish which is being used? Perhaps the MIH protocol has functionality like "STARTTLS"? draft-ietf-mipshop-mos-dns-discovery-02 supports MIH-over-SCTP as well, but this document doesn't -- should they be aligned, and if so, which one needs to be changed? The examples use real domain names (which are owned by someone). I'd suggest changing to RFC 2606 names (example.com etc.), unless there are really good reasons not to do so. |
2008-09-25
|
12 | Tim Polk | [Ballot discuss] This is a discuss - discuss. After discussion, I will either clear or revise to make this actionable. Section 5 puts a lot … [Ballot discuss] This is a discuss - discuss. After discussion, I will either clear or revise to make this actionable. Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?) Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MIH message Size in 6.1 and rate in 6.2) ? |
2008-09-25
|
12 | Tim Polk | [Ballot discuss] This is a discuss - discuss. After discussion, I will either clear or revise to make this actionable. Section 5 puts a lot … [Ballot discuss] This is a discuss - discuss. After discussion, I will either clear or revise to make this actionable. Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?) Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MeIH message Size in 6.1 and rate in 6.2) ? |
2008-09-25
|
12 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2008-09-25
|
12 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2008-09-25
|
12 | Pasi Eronen | [Ballot discuss] I have read draft-ietf-mipshop-mstp-solution-06. It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't done yet), … [Ballot discuss] I have read draft-ietf-mipshop-mstp-solution-06. It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't done yet), but I have the following concerns that I'd like to discuss: In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem inconsistent (MoSV is defined as "anything that isn't a MoSh", and MoS3 is defined as "anything that isn't a MoSh or MoSV" -- wouldn't that make MoS3 an empty set?). The document assumes that NAI can be used to identify a MIHF endpoint; but usually NAI identifies a user account which can be used simultaneously on multiple hosts (each of which would be a separate MIHF endpoint). How does this work? It seems that both MIH-over-TLS-over-TCP and MIH-over-TCP use the same port number (likewise for DTLS/UDP case) -- how does the recipient distinguish which is being used? Perhaps the MIH protocol has functionality like "STARTTLS"? (if so, it should be briefly described here) The examples use real domain names (which are owned by someone). I'd suggest changing to RFC 2606 names (example.com etc.), unless there are really good reasons not to do so. |
2008-09-25
|
12 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-09-25
|
12 | Dan Romascanu | [Ballot discuss] As there are no known implementations or vendor plans to implement the specification (according to the proto write-up) I am wondering why this … [Ballot discuss] As there are no known implementations or vendor plans to implement the specification (according to the proto write-up) I am wondering why this document is aiming standards track. Most of the protocol documents in mipshop have been approved until now as Experimental or Informational. Moreover I could not map this document to any of the items in the mipshop WG charter or list of deliverables (no mention of 802.21 there) to help me understand whether this was the intention of the WG from the start and why. |
2008-09-25
|
12 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2008-09-25
|
12 | Lars Eggert | [Ballot comment] Last Edited Date: 2008-09-25 Section 6.1., paragraph 4: > In terms of dealing with short messages, TCP has the capability to > … [Ballot comment] Last Edited Date: 2008-09-25 Section 6.1., paragraph 4: > In terms of dealing with short messages, TCP has the capability to > concatenate very short messages in order to reduce the overall > bandwidth overhead. However, this reduced overhead comes at the cost > of additional delay to complete an MIH transaction, which may not be > acceptable for CS and ES services. The only delay with TCP (assuming Nagle is turned off) is the connection setup delay, i.e., a delay on the very first MIH exchange. Because subsequent exchanges go over an already established connection, there is no additional latency. (Other than head-of-line blocking under heavy loss due to retransmissions.) Section 6.2., paragraph 1: > Therefore a burst of either > short CS/ES messages or long IS message exchanges (in the case where > multiple MIH nodes request information) may lead to network > congestion. While the built-in rate-limiting controls available in > TCP may be well suited for dealing with these congestion conditions, > this may result in large transmission delays that may be unacceptable > for the timely delivery of ES/CS messages. TCP backs off if there is packet loss, and yes, performance may degrade. But UDP is no magic bullet, either - UDP packets in such scenarios are lost in the same way as TCP packet, and delivery over UDP is unlikely to be more timely than with TCP. Section 6.3., paragraph 3: > An MIH message is retransmitted if its corresponding MIH ACK is not > received by the generating node within a timeout interval set by the > MIHF. This approach does not include an exponential backoff and > therefore tends to degrade more gracefully than TCP when the packet > loss rate becomes large, in the sense that the expected delay does > not increase exponentially. The number of retransmissions is > limited, which reduces head-of-line blocking of other MIH messages, > but this can cause important ES/CS messages to be lost. The default > number of retransmissions is set to 2 and retransmissions are > controlled by a timer with a default value of 10s. No backoff > mechanism is specified. I don't buy this. If you wait 10s before the first retransmit and then try another one after 20s, TCP will have long retransmitted the lost packets, because its RTO is based on the RTT, which is typically much less than 10s. UDP will only be faster if much more aggressive timers are used here, which is problematic. I'd like to request that the text around what timers values are permissible be tightened using 2119 language. (I believe this is part of Magnus' discuss, so I'll leave this as a comment for now. I may upgrade this to a discuss if Magnus' discuss doesn't include this bit.) Section 6., paragraph 1: > Given the reliability requirements for > the MIH transport, it is assumed in this discussion that the MIH ACK > mechanism is to be used in conjunction with UDP, while it is > preferred to avoid using MIH ACKs with TCP since TCP includes > acknowledgement and retransmission functionality. Given the reliability requirements, shouldn't this text REQUIRE MIH ACKs with UDP and say they MUST NOT be used with TCP? (I can't come up with a reason to permit anything else.) Section 6.3., paragraph 2: > If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. See above, I think your reliability requirements make this a MUST. Section 6.1., paragraph 5: > The use of the PUSH bit can alleviate this problem by triggering > transmission of a segment less than the SMSS. The PUSH bit is not under the control of an application that uses TCP. I believe you mean that the Nagle algorithm (RFC896) should be disabled. Section 6.2., paragraph 3: > o If MIHF knows the RTT, the rate can be based upon this How? Section 6.3., paragraph 1: > For TCP, the retransmission timeout is adjusted according to the > measured RTT. However due to the exponential backoff mechanism, the > delay associated with retransmission timeouts may increase > significantly with increased packet loss. And that is a *feature* - it's why Internet congestion control works. |
2008-09-25
|
12 | Lars Eggert | [Ballot discuss] Last Edited Date: 2008-09-25 I refreshed my memory on the previous discussion between transport folks and MIPSHOP, and this is a significant edit … [Ballot discuss] Last Edited Date: 2008-09-25 I refreshed my memory on the previous discussion between transport folks and MIPSHOP, and this is a significant edit of my earlier discuss and comment text. The use of both UDP and TCP by MIH is OK, but I'd like to see stronger text that recommends or even requires which protocol should be used for which messages (namely, UDP for ES/CS messages that are guaranteed to be < 512 bytes and TCP for all IS messages). I also have a discuss-discuss, i.e., a point that I'd like to make sure we've discussed before I clear. It seems that SCTP (esp. partial reliability SCTP) would be the ideal transport for MIH, given that it was designed especially for telephony-like signaling. The document doesn't even mention SCTP as an option. Has the WG considered SCTP and if yes, why wasn't it chosen? |
2008-09-24
|
12 | Cullen Jennings | [Ballot discuss] The document seems to recommend a 24 hour keep alive timer for TCP connections. Most NATs and middle boxes I have seen need … [Ballot discuss] The document seems to recommend a 24 hour keep alive timer for TCP connections. Most NATs and middle boxes I have seen need something more like 2 hours, however the underlying OS TCP stacks typically do this without people being aware of it. Could the authors have a look and check the document says what they want. I'm OK with 24 hours if that is what people really meant but it surprises me. |
2008-09-24
|
12 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2008-09-24
|
12 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-09-24
|
12 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-09-24
|
12 | Russ Housley | [Ballot comment] David Black did a Gen-ART Review during Last Call. Please respond to the concerns raised in this review. |
2008-09-24
|
12 | Russ Housley | [Ballot discuss] David Black did a Gen-ART Review during Last Call. I have not seen a response to his review. I am especially concerned … [Ballot discuss] David Black did a Gen-ART Review during Last Call. I have not seen a response to his review. I am especially concerned about two issues raised in this review. First, Section 6.3 says: > > The default number of retransmissions is set to 2 and retransmissions > are controlled by a timer with a default value of 10s. > Those values appear to be reasonable. Please say that they SHOULD be used, possibly with some qualification involving network-specific characteristics. Second, IS messages are the primary source of large messages, and IS messages do not have tight latency requirements. So, David asks if it is appropriate to say that TCP SHOULD be used for IS messages. |
2008-09-24
|
12 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2008-09-24
|
07 | (System) | New version available: draft-ietf-mipshop-mstp-solution-07.txt |
2008-09-23
|
12 | Magnus Westerlund | [Ballot discuss] This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be … [Ballot discuss] This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be wrong in my understanding of the issue. Section 6.3: If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. An MIH message is retransmitted if its corresponding MIH ACK is not received by the generating node within a timeout interval set by the MIHF. This approach does not include an exponential backoff and therefore tends to degrade more gracefully than TCP when the packet loss rate becomes large, in the sense that the expected delay does not increase exponentially. The number of retransmissions is limited, which reduces head-of-line blocking of other MIH messages, but this can cause important ES/CS messages to be lost. The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s. No backoff mechanism is specified. I am deeply worried over this retransmission scheme. The reason is that it will give so poor performance compared to an scheme with exponential back-off, RTT measurements and more reasonably set default timers. Due to the bad performance I think people will change the retransmission number to a higher value and reduce the timer to a much smaller value. In which case the lack of exponetial back-off can have bad effects on the network. I haven't looked at the MIH layer and what functions it provide. To give good performance I hope there is the following facilities available: - sequence number for duplication and reordering detection - possibility to timestamp or at least measure the RTT reasonably I know to little about your requirement and capability to give really good recommendations. However, instead of reinventing the wheel why not always use TCP? If the MN anyway are going to have a persistent connection with the MoS then there are no extra delay compared to UDP to send TCP. And with the specified retransmission protocol TCP will retranstmitt quicker and more optimized. Section 6.4: 6.4. NAT Traversal There are no known issues for NAT traversal when using TCP. The default connection timeout of 24 hours is considered adequate for MIH transport purposes. If the TCP connection goes through a NAT box also that is subject to binding loss. However, the timeouots are much more reasonable. However, issues with NAT traversal using UDP are documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication failures are experienced when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Hence, communication between the MN and the MoS SHOULD be able to gracefully handle such failures and implement mechanisms to re-establish their UDP sessions. In addition and in order to avoid such failures, MIH messages MAY be sent periodically, similarly to keep-alive messages, to attempt to refresh middlebox state. As [RFC4787] requires a minimum state timeout of two minutes or more, MIH messages using UDP as transport SHOULD be sent once every two minutes. Re-registration or Event indication messages as defined in [IEEE80221] MAY be used for this purpose. If the MN has to send keep-alive messages to keep the binding open for MoS -> MN traffic you are going to have to send a lot of traffic. It is not clear if you have messages that goes in that direction, but if you have having a permanent TCP connection with keep-alives every 15-30 minutes seems much more useful. I am fumbling in the dark here a bit as I don't understand which usage requirements you have, and how the the deployment model looks and between which nodes you really expect NATs to appear. |
2008-09-23
|
12 | Magnus Westerlund | [Ballot comment] Section 6. Given the reliability requirements for the MIH transport, it is assumed in this discussion that the MIH ACK mechanism … [Ballot comment] Section 6. Given the reliability requirements for the MIH transport, it is assumed in this discussion that the MIH ACK mechanism is to be used in conjunction with UDP, while it is preferred to avoid using MIH ACKs with TCP since TCP includes acknowledgement and retransmission functionality. It is normally not the ACK themselves that are the issue with reliability within TCP, it is the retransmissions that build up a sending queue further delaying and also requiring duplication handling. I assume there is retransmission functionality for non-reliable transports, those really SHOULD NOT be used when sending over reliable transports. Section 6.1: It should be noted that MIH layer fragmentation MUST NOT be used together with IP layer fragmentation as specified in [IEEE80221]. From this side it is not clear which should be relied on. Considering NAT traversal and performance implications I think recommending against usage of IP fragmentation is the right one. But that is not knowing which facilities MIH layer fragmentation provides. Can you please clarify this. |
2008-09-23
|
12 | Magnus Westerlund | [Ballot discuss] This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be … [Ballot discuss] This is a discuss, and it really means discuss with me about what I perceive as an issue. I may very well be wrong in my understanding of the issue. Section 6.3: If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. An MIH message is retransmitted if its corresponding MIH ACK is not received by the generating node within a timeout interval set by the MIHF. This approach does not include an exponential backoff and therefore tends to degrade more gracefully than TCP when the packet loss rate becomes large, in the sense that the expected delay does not increase exponentially. The number of retransmissions is limited, which reduces head-of-line blocking of other MIH messages, but this can cause important ES/CS messages to be lost. The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s. No backoff mechanism is specified. I am deeply worried over this retransmission scheme. The reason is that it will give so poor performance compared to an scheme with exponential back-off, RTT measurements and more reasonably set default timers. Due to the bad performance I think people will change the retransmission number to a higher value and reduce the timer to a much smaller value. I haven't looked at the MIH layer and what functions it provide. To give good performance I hope there is the following facilities available: - sequence number for duplication and reordering detection - possibility to timestamp or at least measure the RTT reasonably I know to little about your requirement and capability to give really good recommendations. However, instead of reinventing the wheel why not always use TCP? If the MN anyway are going to have a persistent connection with the MoS then there are no extra delay compared to UDP to send TCP. And with the specified retransmission protocol TCP will retranstmitt quicker and more optimized. Section 6.4: 6.4. NAT Traversal There are no known issues for NAT traversal when using TCP. The default connection timeout of 24 hours is considered adequate for MIH transport purposes. If the TCP connection goes through a NAT box also that is subject to binding loss. However, the timeouots are much more reasonable. However, issues with NAT traversal using UDP are documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication failures are experienced when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Hence, communication between the MN and the MoS SHOULD be able to gracefully handle such failures and implement mechanisms to re-establish their UDP sessions. In addition and in order to avoid such failures, MIH messages MAY be sent periodically, similarly to keep-alive messages, to attempt to refresh middlebox state. As [RFC4787] requires a minimum state timeout of two minutes or more, MIH messages using UDP as transport SHOULD be sent once every two minutes. Re-registration or Event indication messages as defined in [IEEE80221] MAY be used for this purpose. If the MN has to send keep-alive messages to keep the binding open for MoS -> MN traffic you are going to have to send a lot of traffic. It is not clear if you have messages that goes in that direction, but if you have having a permanent TCP connection with keep-alives every 15-30 minutes seems much more useful. |
2008-09-23
|
12 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-09-23
|
12 | Lars Eggert | [Ballot comment] Section 6., paragraph 1: > Given the reliability requirements for > the MIH transport, it is assumed in this discussion that … [Ballot comment] Section 6., paragraph 1: > Given the reliability requirements for > the MIH transport, it is assumed in this discussion that the MIH ACK > mechanism is to be used in conjunction with UDP, while it is > preferred to avoid using MIH ACKs with TCP since TCP includes > acknowledgement and retransmission functionality. Given the reliability requirements, shouldn't this text REQUIRE MIH ACKs with UDP and say they MUST NOT be used with TCP? (I can't come up with a reason to permit anything else.) Section 6.3., paragraph 2: > If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. See above, I think your reliability requirements make this a MUST. Section 6.1., paragraph 5: > The use of the PUSH bit can alleviate this problem by triggering > transmission of a segment less than the SMSS. The PUSH bit is not under the control of an application that uses TCP. I believe you mean that the Nagle algorithm (RFC896) should be disabled. Section 6.2., paragraph 3: > o If MIHF knows the RTT, the rate can be based upon this How? Section 6.3., paragraph 1: > For TCP, the retransmission timeout is adjusted according to the > measured RTT. However due to the exponential backoff mechanism, the > delay associated with retransmission timeouts may increase > significantly with increased packet loss. And that is a *feature* - it's why Internet congestion control works. |
2008-09-23
|
12 | Lars Eggert | [Ballot discuss] Section 6., paragraph 0: > 6. MIH Transport Options DISCUSS: I don't quite understand why this document allows both UDP and … [Ballot discuss] Section 6., paragraph 0: > 6. MIH Transport Options DISCUSS: I don't quite understand why this document allows both UDP and TCP, which adds complexity, when TCP alone seems to be a completely adequate transport. Here's why: Section 6.1., paragraph 4: > In terms of dealing with short messages, TCP has the capability to > concatenate very short messages in order to reduce the overall > bandwidth overhead. However, this reduced overhead comes at the cost > of additional delay to complete an MIH transaction, which may not be > acceptable for CS and ES services. The only delay with TCP (assuming Nagle is turned off) is the connection setup delay, i.e., a delay on the very first MIH exchange. Because subsequent exchanges go over an already established connection, there is no additional latency. Section 6.2., paragraph 1: > Therefore a burst of either > short CS/ES messages or long IS message exchanges (in the case where > multiple MIH nodes request information) may lead to network > congestion. While the built-in rate-limiting controls available in > TCP may be well suited for dealing with these congestion conditions, > this may result in large transmission delays that may be unacceptable > for the timely delivery of ES/CS messages. TCP backs off if there is packet loss, and yes, performance may degrade. But UDP is no magic bullet, either - UDP packets in such scenarios are lost in the same way as TCP packet, and delivery over UDP is unlikely to be more timely than with TCP. Section 6.3., paragraph 3: > An MIH message is retransmitted if its corresponding MIH ACK is not > received by the generating node within a timeout interval set by the > MIHF. This approach does not include an exponential backoff and > therefore tends to degrade more gracefully than TCP when the packet > loss rate becomes large, in the sense that the expected delay does > not increase exponentially. The number of retransmissions is > limited, which reduces head-of-line blocking of other MIH messages, > but this can cause important ES/CS messages to be lost. The default > number of retransmissions is set to 2 and retransmissions are > controlled by a timer with a default value of 10s. No backoff > mechanism is specified. I don't buy this. If you wait 10s before the first retransmit and then try another one after 20s, TCP will have long retransmitted the lost packets, because its RTO is based on the RTT, which is typically much less than 10s. UDP will only be faster if much more aggressive timers are used here, which is problematic. |
2008-09-23
|
12 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2008-09-18
|
12 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2008-09-18
|
12 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Patrick Cain. |
2008-09-18
|
12 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-09-17
|
12 | Amanda Baber | IANA Last Call comments: Upon approval of this document, the IANA understands that it must complete a single action. IANA will assign a port number … IANA Last Call comments: Upon approval of this document, the IANA understands that it must complete a single action. IANA will assign a port number from the registered port range for the following UDP and TCP ports: Port Short Name Decimal Description -------- --------------- ------------ ieee-mih TBD/tcp MIH Services ieee-mih TBD/udp MIH Services IANA understands that this is the only action required upon approval of this document. |
2008-09-05
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Patrick Cain |
2008-09-05
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Patrick Cain |
2008-09-04
|
12 | Amy Vezza | Last call sent |
2008-09-04
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-09-04
|
12 | Jari Arkko | placed on agenda |
2008-09-04
|
12 | Jari Arkko | Placed on agenda for telechat - 2008-09-25 by Jari Arkko |
2008-09-04
|
12 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2008-09-04
|
12 | Jari Arkko | Last Call was requested by Jari Arkko |
2008-09-04
|
12 | Jari Arkko | Ballot has been issued by Jari Arkko |
2008-09-04
|
12 | Jari Arkko | Thanks for the new version. I have looked at it and the previous AD review, and I'm in general satisfied with the result. |
2008-09-04
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-09-04
|
06 | (System) | New version available: draft-ietf-mipshop-mstp-solution-06.txt |
2008-07-31
|
12 | Amanda Baber | IANA Evaluation comments: IESG NOTE: Expert Review Required Upon approval of this document, the IANA will make the following assignments in the "PORT NUMBERS" registry … IANA Evaluation comments: IESG NOTE: Expert Review Required Upon approval of this document, the IANA will make the following assignments in the "PORT NUMBERS" registry at http://www.iana.org/assignments/port-numbers sub-registry "REGISTERED PORT NUMBERS" Keyword Decimal Description References ------- ------- ----------- ---------- ieee-mih-IS TBD_BY_IANA/tcp MIH Information Services [RFC-mipshop-mstp-solution-05] ieee-mih-IS TBD_BY_IANA/udp MIH Information Services [RFC-mipshop-mstp-solution-05] ieee-mih-ES TBD_BY_IANA/tcp MIH Event Services [RFC-mipshop-mstp-solution-05] ieee-mih-ES TBD_BY_IANA/udp MIH Event Services [RFC-mipshop-mstp-solution-05] ieee-mih-CS TBD_BY_IANA/tcp MIH Command Services [RFC-mipshop-mstp-solution-05] ieee-mih-CS TBD_BY_IANA/udp MIH Command Services [RFC-mipshop-mstp-solution-05] We understand the above to be the only IANA Action for this document. |
2008-07-11
|
12 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2008-07-11
|
12 | Jari Arkko | Ballot has been issued by Jari Arkko |
2008-07-11
|
12 | Jari Arkko | Created "Approve" ballot |
2008-07-11
|
12 | (System) | Ballot writeup text was added |
2008-07-11
|
12 | (System) | Last call text was added |
2008-07-11
|
12 | (System) | Ballot approval text was added |
2008-07-11
|
12 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko |
2008-07-11
|
12 | Jari Arkko | Few relatively minor issues remaining from Gorry's and AD reviews. |
2008-07-10
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-07-10
|
05 | (System) | New version available: draft-ietf-mipshop-mstp-solution-05.txt |
2008-05-19
|
12 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2008-05-19
|
12 | Jari Arkko | I have made my AD review of this document. Please find details below. Overall, there were a few important missing or underspecified parts relating to … I have made my AD review of this document. Please find details below. Overall, there were a few important missing or underspecified parts relating to parameters and algorithms for using UDP, discovery via another MoS, NAT-traversal retransmissions, and authorization. These should be specified. The security mechanisms should be narrowed down to a more reasonable set. But the big question for me was whether it is appropriate to employ DHCP-AAA binding so that per-MN information can be provided. I realize that we have done it once in the context of the Mobile IP bootstrapping work. But frankly, that sets a very high bar for deployment in a given access network and introduces dependencies and complexity that is undesirable. In general, if every application that wants to avoid configuration needs to have special support in DHCP relays, it becomes very hard to deploy anything new. My read of RFC 5164 does not say that the AAA binding is required. My question is whether (a) local MIH services, (b) configured home network name and DNS, (c) local MIH IS + redirection to home MIH, (d) other Internet service discovery mechanisms would be sufficient or preferable. At the very least, we should consider publishing the simple solution first, and only if there's actual evidence of deployments with more complex requirements, consider extending it. Process: Given the extensive use of DHCP in this document, we need to engage the DHC WG in a discussion of this draft. I would also like to see a transport directorate review. Both to be done after a revision addressing my own comments has been submitted, however. Technical: > DHCP Dynamic Host Configuration Protocol: a protocol described in > [RFC2131] that allows Internet devices to obtain IP addresses, > subnet masks, default gateway addresses, and other IP > configuration information from DHCP servers. IPv6 needs to be covered as well. Please add the appropriate reference. > Different types of MoS can be provided independently of other types > and there is no strict relationship between ES, CS and IS, nor is > there a requirement that the entities that provide these services > should be co-located. However, while IS tends to involve a large > amounts of static information, ES and CS are dynamic services and > some relationships between them can be expected, e.g., a handover > command (CS) could be issued upon reception of a link event (ES). > Hence, while in theory MoS can be implemented in different locations, > it is expected that ES and CS will be co-located, whereas IS can be > co-located with ES/CS or located elsewhere. Therefore, having the > flexibility at the MSTP to discover different services in different > locations is an important feature that can be used to optimize > handover performance. MoS discovery is discussed in more detail in > Section 5. Is there a need to state that ES/CS is more likely to be associated with a visited network than home? > The configuration of the MoS could be executed either upon network > attachment or after successful IP configuration. The methodology to > be used depends on the considered deployment scenario. First, there's a problem here with what kind of network attachment we are talking about. I believe mobility services need to be provided from the access network in many situations. IP layer configuration is somewhat independent of the link layer attachments, given things like bridging, access concentrators, tunneling, proxy MIP and so on. Given this, I think the above needs to say that discovery happens upon initial or changed link layer attachment. Secondly, the part about IP configuration needs to talk about changed IP configuration as well. If your DHCP lease expires, and you get a new address, will you redo discovery? What if you generate a new 3041 address? If the prefixes in the RAs change without the routers themselves being changed? What if you do DNAv4 or v6 and detect a network change? Thirdly, I do not think it is appropriate to leave this entirely to deployments. At least for the mobile node side, code needs to be written and every host needs to be able to behave in the correct manner. In conclusion, this text needs to be written in a much more detailed and specification-like manner. It may be that subsequent sections contain at least some of these details. If so, forward references would be needed. > In the case where MoS is provided locally (scenarios S1 and S2) , the > discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options] > and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable and > either one MAY be used to discover the MoS. Dns-discovery requires starting from a known domain name, which seems to exclude using it for local networks. Other than as a follow-up to other methods, like DHCP. > In the case where MoS is provided in the home network while the MN is > in the visited network (scenario S3), the DNS based discovery > described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable, > while the DHCP based discovery method would require an interaction > between the DHCP and the AAA infrastructure, similarly to what is > specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This > latter case assumes that MoS assignment is performed during access > authentication and authorization. I would like to see this simply state that DHCP based discovery in such a scenario is inappropriate for the given reasons. I do not believe it is beneficial to start bundling DHCP with other parts of the network, except where absolutely required. > It should be noted that authorization of a MN to use a specific MoS > server is not in scope of this document and is specified in > [IEEE80221] . This needs expansion. How does the IEEE scheme affect the transport protocol? Can we end up in a situation where DHCP discovery delivers a server address which refuses to talk to us, for instance? > In order to use that > mechanism, the MN MUST first find out the domain name of its home > network. Home domains are usually pre-configured in the MNs (i.e. > subscription is tied to a network), thus the MN can simply read its > configuration data to find out the home domain name (scenario S1). This is formulated in a peculiar way. Wouldn't it be simpler to just say that MNs must be configured with the domain name of their home network? > Alternatively, the MN > MAY use the DHCP options for MoS > discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown inFigure 6b. Again, binding the DHCP process with AAA, knowledge of particular node's home network etc is undesirable. Can we remove this from the draft? > DHCP -- In order to find out the domain name of the local network, > the MN SHOULD use the dhcpv4 option 15 for learning the domain > name [RFC2132]. A similar solution is available for dhcpv6 > [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] . The draft is expired. I would suggest re-considering whether this approach (dchp + dns) is necessary. > Reverse dns query -- When DHCP does not provide the required domain > name, the MN MAY use reverse DNS (DNS PTR record) to find the > domain name associated with the IP address it is using in the > visited network. Note, that when a NAT device exists between the > MN and the visited network, the MN will first need to find out the > external IP address of the NAT device. Some possible methods for > determining the NAT's external IP address are STUN [RFC3849] or > UPnP [UPnP_IDG_DCP]. Once the MN has determined the external IP > address of the NAT device, it MUST use that address in the reverse > DNS query. A lot of complexity. I wonder if this is really needed. Anyone who is willing to deploy a relatively costly service such as the MIS on their network, why would they not be willing to add a few DHCP options to their network as well? Note that you do not need to use DHCP in IPv6 to acquire such options; stateless DHCP would also do fine, and can be combined with autoconfig addresses. > When the discovery of an MoS at the visited network, using the FQDN > returned in the reverse DNS query, is not successful, the MN MAY > attempt to remove portions from the left side of the FQDN and attempt > discovery again. The process MAY be repeated iteratively until a > successful discovery. As in eventually asking for mobility services from .com, for instance? I think you need text to avoid this from happening. > This section assumes the use of IPv6 and DHCPv6 based mechanisms to > discover MoS services in home while the MN is in visited network. If > similar functionalities are desired for IPv4 additional DHCPv4 > extensions would be required. Since use cases requiring these > extensions were not identified at the time of writing this document, > they were excluded from the scope of the document. I am surprised by this. Generally speaking, I would expect to see feature parity for IPv4 and IPv6 in specifications like this. > To discover an MoS in a remote network other than home network, the > MN MUST use the DNS based MoS discovery method described in > [I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the > domain name of the network containing the MoS it is searching for. > If the MN does not yet know the domain name of the network, learning > it may require more than one operation, as DHCP based discovery can > not be used and pre-configuration is not a feasible solution in case > of an arbitrary remote network. The MN MAY attempt to first discover > an MoS in either the local or home network (as in Figure 9 part (a)) > and query that MoS to find out the domain name of a specific network > or the domain name of a network at a specific location (as in > Figure 9 part (b)). Alternatively, the MN MAY query an MoS > previously known to learn the domain name of the desired network > (e.g., via an IS Query). Finally, the MN MUST use DNS queries to > find MoS in the remote network as inFigure 9 part(c). It should be > noted that step c can only be performed upon obtaining the domain > name of the remote network. The part about finding more information from MoS to redirect the mobile node to a third party is vague. Can this document point to specific attributes defined in IEEE that would carry such information? Otherwise this cannot be implemented. Also, its not clear why "pre-configuration is not a feasible solution in case of an arbitrary remote network". Surely its no harder to configure a given 3rd party network than a given home network. I agree that pre-configuration should be avoided if possible, though. > while it is preferred to avoid using MIH ACKs with TCP > since TCP includes acknowledgement and retransmission functionality. Is there no need for application level confirmation? TCP ACKs will only tell you that the message got through, not, for instance, that it can be obeyed. > On the other hand, if UDP > is used, a rate-limiting effect similar to the one obtained with TCP > may be obtained by adequately adjusting the parameters of a token > bucket regulator as defined in the MIH specifications [IEEE80221]. > Recommendations for tocken bucket parameter settings are specific to > the scenario considered. The parameters and algorithms governing the use and timing of UDP need to be specified. Its fine to point to an IEEE spec, but it needs to be clear that they are mandatory. From the above I cannot determine what an implementation needs to do. > As [RFC4787] requires a minimum state timeout of two > minutes or more, MIH messages using UDP as transport SHOULD be sent > once every two minutes. This is too vague. Sent when? If you have an implementation capable of using MIH? When you have something to send, you keep sending it over and over again? When you have something to receive you keep sending something else? How do you know when you have something to receive, or when you want to receive something? Note that it would be very unfortunate if every host in every network that had turned MIH on would be sending a packet every 2 mins. > MIH messages sent over UDP, TCP or other supported > transport MUST use the default port number defined for that > particular transport. Where are these specified? > MIH Transport Options The document is very silent on how MIH messages are carried on a given transport protocol. At the very least the draft should indicate that no extra framing is needed because IEEE specs already contain a length field. > MIH Transport Options The document does not talk about how servers know the capabilities of clients that send event/command services to. Is this a part of the IEEE definitions, and you subscribe to a particular event stream? In any case, the document should talk about this and point to the relevant other specifications where needed. > In the case where DHCP is used for node discovery and authentication > of the source and content of DHCP messages is required, network > administrators SHOULD use DHCP authentication option described in > [RFC3118], where available or rely upon link layer security. This > will also protect the DHCP server against denial of service attacks > to. [RFC3118] provides mechanisms for both entity authentication and > message authentication. I think the overall recommendation is good, but practically no one is going to deploy RFC 3118. With this in mind, I would like to see the above paragraph explain in more detail the security implications of relying on link layer security. > In the case where reliable transport protocol such as TCP is used for > transport connection between two MIHF peers, TLS [RFC4346] SHOULD be > used for message confidentiality and data integrity. In particular, > TLS is designed for client/server applications and to prevent > eavesdropping, tampering, or message forgery. Readers should also > follow the recommendations in [RFC4366] that provides generic > extension mechanisms for the TLS protocol suitable for wireless > environments. > > In the case where unreliable transport protocol such as UDP is used > for transport connection between two MIHF peers, DTLS [RFC4347] > SHOULD be used for message confidentiality and data integrity. The > DTLS protocol is based on the Transport Layer Security (TLS) protocol > and provides equivalent security guarantees. > > Alternatively, generic IP layer security, such as IPSec [RFC4301] MAY > be used where neither transport layer security for a specific > transport is available nor server only authentication is required. Too many options. I do not see a particular requirement for IPsec here, why do we need to include it? Also, are TLS and DTLS mandatory to implement? Editorial: Acronyms used before defined. At least for MSTP (!) and MIHF, maybe others. Expand them on first use, if this happens prior to the terms section. Most entries in Section 2 need to point to the relevant RFC or other specification that defines them. E.g., NAI or ES. Fix these idnits issues: == Unused Reference: 'I-D.ietf-dime-mip6-integrated' is defined on line 1066, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-mip6-bootstrapping-integrated-dhc is -hc, but you're referring to -06. > Since transporting long MIH messages may require > fragmentation that is not available in UDP, ... This needs to be reformulated. UDP itself has no fragmentation support, but IP does. But the issue is that IP layer fragmentation may not work well, particularly for large packets, may cause several other issues, etc. > TCP client I believe it would be more appropriate to talk about the "MSTP client" or "MIH client" or "MSTP TCP client"; TCP does not operate on its own. Or, maybe you can merge "TCP client" and "MIHF" in Figure 10. (Appears in multiple places in the document, as does the corresponding UDP term) > and responses may cause DoS and the inability of the MN to perform a Acronym "DoS" not introduced earlier. |
2008-05-18
|
12 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2008-05-18
|
12 | Jari Arkko | Intended Status has been changed to Proposed Standard from None |
2008-05-15
|
12 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? 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? Vijay Devarapalli is the Document Shepherd for this document. I have reviewed the document and it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by numerous folks, including folks who are proficient in IP Mobility and Security and folks who are active in the IEEE 802.21 WG. I have no concerns about the depth or breadth of the reviews that have been performed. (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? None. (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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. The MIPSHOP WG received numerous liaison statements from the IEEE 802.21 WG supporting this work. The solution described in the document is supposed to provide a Layer 3 protocol for transport of the handover assist information. The IEEE 802.21 WG also provided the requirements for the solution. An IPR was disclosed regarding this document. Please see https://datatracker.ietf.org/ipr/932/. This was posted on the MIPSHOP WG mailing list. There was no objection to progress the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is WG consensus in advancing this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document meets all the requirements. There were three minor nits. 1) One line that is longer than 72 characters 2) An unused reference 3) Reference to a wrong version of draft-ietf-mip6-bootstrapping-integrated-dhc. I believe these are minor nits that can be fixed in the next version of the document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? 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]. The document splits the references into normative and informative references. The document has normative dependencies on draft-ietf-mipshop-mos-dns-discovery and draft-ietf-mipshop-mos-dhcp-options. These documents will also be sent to the IESG soon. Note that these extensions are not necessary for someone to understand the solution framework described in the document. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section exists and is consistent with the body of the document. The document requests reservations in the appropriate IANA registries. The IANA registries that need to be modified/created are clearly identified. (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? Does not apply. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes a solution for discovering IEEE 802.21 Media Independent Handover (MIH) servers (called the MoS server) and a transport layer mechanism for the reliable delivery of MIH messages. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? None. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? There are no known implementations or vendor plans to implement the specification. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Vijay Devarapalli Responsible AD: Jari Arkko/Mark Townsley |
2008-05-15
|
12 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-05-11
|
04 | (System) | New version available: draft-ietf-mipshop-mstp-solution-04.txt |
2008-04-28
|
03 | (System) | New version available: draft-ietf-mipshop-mstp-solution-03.txt |
2008-04-17
|
02 | (System) | New version available: draft-ietf-mipshop-mstp-solution-02.txt |
2008-02-29
|
(System) | Posted related IPR disclosure: InterDigital Technology Corporation's Statement about IPR related to draft-ietf-mipshop-mstp-solution-01 | |
2008-02-12
|
01 | (System) | New version available: draft-ietf-mipshop-mstp-solution-01.txt |
2007-12-17
|
00 | (System) | New version available: draft-ietf-mipshop-mstp-solution-00.txt |