Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent
draft-ietf-mext-mip6-tls-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-05-14
|
05 | Ben Campbell | Request for Last Call review by GENART Completed. Reviewer: Ben Campbell. |
2012-04-24
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-04-24
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-04-24
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-04-12
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-04-02
|
05 | (System) | IANA Action state changed to In Progress |
2012-03-29
|
05 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-03-28
|
05 | Cindy Morgan | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-03-28
|
05 | Cindy Morgan | IESG has approved the document |
2012-03-28
|
05 | Cindy Morgan | Closed "Approve" ballot |
2012-03-28
|
05 | Cindy Morgan | Ballot approval text was generated |
2012-03-28
|
05 | Cindy Morgan | Ballot writeup was changed |
2012-03-28
|
05 | Jari Arkko | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-03-28
|
05 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss and comments! |
2012-03-28
|
05 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-03-28
|
05 | Jouni Korhonen | New version available: draft-ietf-mext-mip6-tls-05.txt |
2012-03-12
|
04 | Stephen Farrell | [Ballot discuss] So while this seems to be quite a good idea, I've a couple of things I want to understand...(oops - added #3 below, … [Ballot discuss] So while this seems to be quite a good idea, I've a couple of things I want to understand...(oops - added #3 below, forgot that) #1 Has the security of the auth protocol in 5.8 been studied much? If so, where is that described? I'm surprised there's nothing directional to prevent reflection attacks or cross-protocol attacks, e.g. by including MN and HAC-specific strings in the HMAC input. As-is, it also looks like messages 2 and 3 could maybe be reflected. It also looks like messges can be replayed since the tls-server-end-point CB-octets are fixed per-hac. Since CB-octets are essentially public, guesses of the MN's PSK are also possible, if that is somehow human-memorable. This all looks like a problem to me that needs to be looked at even for an experimental spec, or maybe I'm misreading something. (I guess similar concerns might exist for the eap method in 5.9 as well.) #2 If MN authentication is done above TLS then you might need to ensure that TLS implementations are not vulnerable to the TLS re-negotiation bug. (See RFC 5746.) Did you think that thgrough? Might be worth noting in the security considerations even though the MN<->HAC authentiction scheme uses channel-bindings, just in case. (Actually since the CB-octets are not session-specific this might be a gotcha too.) #3 cleared |
2012-03-12
|
04 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2012-03-12
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-03-12
|
04 | Jouni Korhonen | New version available: draft-ietf-mext-mip6-tls-04.txt |
2012-03-12
|
03 | Peter Saint-Andre | [Ballot comment] Thank you for clarifying the rules about TLS authentication and identity checking (in version -04). |
2012-03-12
|
03 | Peter Saint-Andre | [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss |
2012-03-01
|
03 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Tobias Gondrom. |
2012-03-01
|
03 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead |
2012-03-01
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-02-29
|
03 | Stephen Farrell | [Ballot comment] - I don't see why MN authentication has to be done outside the TLS session setup (handshake). TLS supports client authentication and its … [Ballot comment] - I don't see why MN authentication has to be done outside the TLS session setup (handshake). TLS supports client authentication and its not clear why that couldn't be used here instead of the scheme in 5.8/5.9. - Isn't there already a way to do EAP over TLS? Why invent a new one? I think you should say why, if its justified. (e.g. RFC 5281.) - 4.2: I guess you also need mutual authentication between non-colocated HAC and HA instances? (That might seem like nit-picking, but there are ways to get integ. & confid. without knowing for sure from whom stuff is coming.) - I'm a bit surprised that you don't want to use RFC5705 to extract some key material from TLS sessions. Worth considering and/or noting as a possible future improvement? - 5.6 seems a bit brittle - if TLS changes the set of preferred ciphersuites that could in principle result in a mismatch between the TLS preferred ciphersuites and what's doable between MN and HA. - In 5.8 you don't seem to have algorithm agility for your "auth" algorithm - can it be other than HMAC-SHA256? Maybe ok for an experimental RFC though but worth noting. - In 5.8 after figure 4, step 2, what is msg-octets when none of the optional fields are included? The description in the last two paragraphs seems a bit broken too. (2nd last para should be about step 2 I thought) - As commonly used, TLS doesn't quite give the same level of security as IPsec as commonly used. IPsec has perfect forward secrecy due to its use of D-H, whereas TLS with RSA key transport does not. That means that a later exposure of a server RSA private key (e.g. if de-commissioned h/w isn't properly scrubbed) potentially allows anyone to recover TLS pre-master keys from any recorded TLS sessions. That's worth noting so that if someone does deploy this, they know to not just sell old server h/w that used to store RSA private keys on disk. - TLS with RSA key transport also relies on the entropy provided by the client for security. That has been a source of known problems over the years (including very recently) and so is also worth noting since the client here is a mobile node that might just have been turned on and so not have lots of entropy. - While TLS protects against replays, if somehow I get the auth protocol messages then I can replay those in a new TLS session with the HAC so the text in the security considerations on this point might need to change depending on the discuss pionts above. - There're some points worth noting in the secdir review as well. http://www.ietf.org/mail-archive/web/secdir/current/msg03131.html |
2012-02-29
|
03 | Stephen Farrell | Ballot comment text updated for Stephen Farrell |
2012-02-29
|
03 | Russ Housley | [Ballot comment] Please see the comments in the Gen-ART Review by Ben Campbell on 28-Feb-2012. The comment that causes me the greatest concern … [Ballot comment] Please see the comments in the Gen-ART Review by Ben Campbell on 28-Feb-2012. The comment that causes me the greatest concern is covered by the (updated) DISCUSS position from Stephen Farrell. Please consider all of Ben's review comments: http://www.ietf.org/mail-archive/web/gen-art/current/msg07232.html |
2012-02-29
|
03 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-02-29
|
03 | Stephen Farrell | [Ballot discuss] So while this seems to be quite a good idea, I've a couple of things I want to understand...(oops - added #3 below, … [Ballot discuss] So while this seems to be quite a good idea, I've a couple of things I want to understand...(oops - added #3 below, forgot that) #1 Has the security of the auth protocol in 5.8 been studied much? If so, where is that described? I'm surprised there's nothing directional to prevent reflection attacks or cross-protocol attacks, e.g. by including MN and HAC-specific strings in the HMAC input. As-is, it also looks like messages 2 and 3 could maybe be reflected. It also looks like messges can be replayed since the tls-server-end-point CB-octets are fixed per-hac. Since CB-octets are essentially public, guesses of the MN's PSK are also possible, if that is somehow human-memorable. This all looks like a problem to me that needs to be looked at even for an experimental spec, or maybe I'm misreading something. (I guess similar concerns might exist for the eap method in 5.9 as well.) #2 If MN authentication is done above TLS then you might need to ensure that TLS implementations are not vulnerable to the TLS re-negotiation bug. (See RFC 5746.) Did you think that thgrough? Might be worth noting in the security considerations even though the MN<->HAC authentiction scheme uses channel-bindings, just in case. (Actually since the CB-octets are not session-specific this might be a gotcha too.) #3 The draft seems to be missing information on how to match TLS certificates to identities for HAC authentication. |
2012-02-29
|
03 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2012-02-29
|
03 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-02-29
|
03 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-02-29
|
03 | Stephen Farrell | [Ballot discuss] So while this seems to be quite a good idea, I've a couple of things I want to understand... #1 Has the security … [Ballot discuss] So while this seems to be quite a good idea, I've a couple of things I want to understand... #1 Has the security of the auth protocol in 5.8 been studied much? If so, where is that described? I'm surprised there's nothing directional to prevent reflection attacks or cross-protocol attacks, e.g. by including MN and HAC-specific strings in the HMAC input. As-is, it also looks like messages 2 and 3 could maybe be reflected. It also looks like messges can be replayed since the tls-server-end-point CB-octets are fixed per-hac. Since CB-octets are essentially public, guesses of the MN's PSK are also possible, if that is somehow human-memorable. This all looks like a problem to me that needs to be looked at even for an experimental spec, or maybe I'm misreading something. (I guess similar concerns might exist for the eap method in 5.9 as well.) #2 If MN authentication is done above TLS then you might need to ensure that TLS implementations are not vulnerable to the TLS re-negotiation bug. (See RFC 5746.) Did you think that thgrough? Might be worth noting in the security considerations even though the MN<->HAC authentiction scheme uses channel-bindings, just in case. (Actually since the CB-octets are not session-specific this might be a gotcha too.) |
2012-02-29
|
03 | Stephen Farrell | [Ballot comment] - I don't see why MN authentication has to be done outside the TLS session setup (handshake). TLS supports client authentication and its … [Ballot comment] - I don't see why MN authentication has to be done outside the TLS session setup (handshake). TLS supports client authentication and its not clear why that couldn't be used here instead of the scheme in 5.8/5.9. - Isn't there already a way to do EAP over TLS? Why invent a new one? I think you should say why, if its justified. (e.g. RFC 5281.) - 4.2: I guess you also need mutual authentication between non-colocated HAC and HA instances? (That might seem like nit-picking, but there are ways to get integ. & confid. without knowing for sure from whom stuff is coming.) - I'm a bit surprised that you don't want to use RFC5705 to extract some key material from TLS sessions. Worth considering and/or noting as a possible future improvement? - 5.6 seems a bit brittle - if TLS changes the set of preferred ciphersuites that could in principle result in a mismatch between the TLS preferred ciphersuites and what's doable between MN and HA. - In 5.8 you don't seem to have algorithm agility for your "auth" algorithm - can it be other than HMAC-SHA256? Maybe ok for an experimental RFC though but worth noting. - In 5.8 after figure 4, step 2, what is msg-octets when none of the optional fields are included? The description in the last two paragraphs seems a bit broken too. (2nd last para should be about step 2 I thought) - As commonly used, TLS doesn't quite give the same level of security as IPsec as commonly used. IPsec has perfect forward secrecy due to its use of D-H, whereas TLS with RSA key transport does not. That means that a later exposure of a server RSA private key (e.g. if de-commissioned h/w isn't properly scrubbed) potentially allows anyone to recover TLS pre-master keys from any recorded TLS sessions. That's worth noting so that if someone does deploy this, they know to not just sell old server h/w that used to store RSA private keys on disk. - TLS with RSA key transport also relies on the entropy provided by the client for security. That has been a source of known problems over the years (including very recently) and so is also worth noting since the client here is a mobile node that might just have been turned on and so not have lots of entropy. - While TLS protects against replays, if somehow I get the auth protocol messages then I can replay those in a new TLS session with the HAC so the text in the security considerations on this point might need to change depending on the discuss pionts above. |
2012-02-29
|
03 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-02-29
|
03 | Adrian Farrel | [Ballot comment] I am balloting No Objection on the assumption that this has been thoroughly reviewed by the INT ADs and the Security Directorate. |
2012-02-29
|
03 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-02-29
|
03 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-02-29
|
03 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-02-28
|
03 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-02-28
|
03 | Peter Saint-Andre | [Ballot discuss] Section 9.2 states that "Server-side certificate based authentication MUST be performed using TLS 1.2 [RFC5246]" but that "The client-side authentication may … [Ballot discuss] Section 9.2 states that "Server-side certificate based authentication MUST be performed using TLS 1.2 [RFC5246]" but that "The client-side authentication may depend on the specific deployment and is therefore not mandated." However, you don't say anything about the basis for authentication or identity checking. What identifiers need to be in the certificates? How are those identifiers checked? What are the rules? We can't just wave our hands here, else interoperability will be impossible (as will real security). Profiling RFC 6125 might make sense, if the identifiers are domain names. If the identifiers are IP addresses, then life is simpler, but we would still need to say something about identity checking. |
2012-02-28
|
03 | Peter Saint-Andre | [Ballot Position Update] New position, Discuss, has been recorded for Peter Saint-Andre |
2012-02-23
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2012-02-23
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2012-02-23
|
03 | Jean Mahoney | Assignment of request for Last Call review by GENART to Francis Dupont was rejected |
2012-02-23
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2012-02-23
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2012-02-20
|
03 | Jari Arkko | Placed on agenda for telechat - 2012-03-01 |
2012-02-18
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2012-02-18
|
03 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2012-02-16
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-02-16
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-02-15
|
03 | Amy Vezza | Last call sent |
2012-02-15
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication) to Experimental RFC The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Mobile IPv6 signaling between a mobile node and its home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/ IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mext-mip6-tls/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mext-mip6-tls/ No IPR declarations have been submitted directly on this I-D. |
2012-02-15
|
03 | Jari Arkko | Last Call was requested |
2012-02-15
|
03 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2012-02-15
|
03 | Jari Arkko | Last Call text changed |
2012-02-15
|
03 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2012-02-15
|
03 | Jari Arkko | Ballot has been issued |
2012-02-15
|
03 | Jari Arkko | Created "Approve" ballot |
2012-02-15
|
03 | (System) | Ballot writeup text was added |
2012-02-15
|
03 | (System) | Last call text was added |
2012-02-14
|
03 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2012-02-14
|
03 | (System) | New version available: draft-ietf-mext-mip6-tls-03.txt |
2011-12-29
|
03 | Jari Arkko | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. |
2011-12-29
|
03 | Jari Arkko | I have reviewed this specification. I think it is in good shape and almost ready to move forward. I have some comments below, please address … I have reviewed this specification. I think it is in good shape and almost ready to move forward. I have some comments below, please address them in a new revision of the draft. My main comments relate to sequence numbers, Section 7, and IANA considerations. > The HAC can be co-located with the HA, or can be an > independent entity. For the latter case, communication between HAC > and HA is not defined by this document. The Diameter protocol can be > used between the HA and HAC when the two entities are not collocated. I'd change the last sentence to: "Such communication could be built on top of AAA protocols such as Diameter, for instance." (You can't just use Diameter, you'd have to define a specific way of doing it.) > The security framework proposed in this document is not intended to > replace the currently specified architecture which relies on IPsec > and IKEv2. It provides an alternative solution which is more optimal > for certain deployment scenarios. Add to the end: This and other alternative security models have been considered by the MEXT working group at the IETF, and it has been decided that the alternative solutions should be published as Experimental RFCs, so that more implementation and deployment experience with these models can be gathered. The working group may reconsider the status of the different models in the future, if it becomes clear that one is superior to the others. > Mobile IPv6 implementation complexity increases quite dramatically. I would just say "... complexity increases." > At an abstract level it can > be said that implementing Mobile IPv6 with IPsec and IKEv2 is > possible only with modifications to the IPsec and IKEv2 components. > The original design intent was to reuse IPsec without having to > modify them. The current security model requires an IPsec/IKEv2 > implementation that is specific to Mobile IPv6. I don't think this is quite right. I'd reword to: Implementing Mobile IPv6 with IPsec and IKEv2 requires modifications to both the IPsec and IKEv2 components, due to the communication models that Mobile IPv6 uses and the changing IP addresses. For further details, see Section 7.1 in [RFC3776]. Section 3 felt a little bit duplicated text from Section 1. Might be an idea to look at merging the two. Don't spend too much effort on that however, I can live with the current two sections as well. > Sequence numbers: > > A monotonically increasing unsigned sequence number used in all > protected packets exchanged between the MN and the HA in the same > direction. Sequence numbers are maintained per direction, so each > SA includes two independent sequence numbers (MN -> HA, HA -> MN). > The initial sequence number for each direction MUST always be set > to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing > beyond their maximum defined value. I don't understand why sequence numbers have to be agreed on between the MN and HAC. Perhaps the use of sequence numbers should be, not the numbers themselves? Please clarify. > form of a Network Access Identifier (NAI) [RFC4282]. > > mn-id = "mn-id" ":" nai CRLF > nai = username > | "@" realm > | username "@" realm > ... I'd prefer you to just say after the first line that "nai" is as defined in RFC4282, not repeat the definition here. Or if you do repeat it, please indicate that it is copied here for convenience. Otherwise people have to go back to RFC 4282 and check that the definition is the same. (I did that, for instance.) You should use ABNF, please respecify the syntax in ABNF. If I take your syntax and change "|" to "/" I still get at least one error here: > > mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date > CRLF > The HAC SHOULD provision the MN with an UDP port number, where the HA > expects to receive UDP packets. If this parameter is not present, This comes suddenly for the reader, who at this point has not been introduced to the change that you run everything on top of UDP. Please explain this better earlier in the document. > The SPI value is followed by a 32-bit Sequence Number value that is > used to identify retransmissions of encrypted messages. Each > endpoint in the security association maintains two "current" Sequence > Numbers: the next one to be used for a packet it initiates and the > next one it expects to see in a packet from the other end. If the MN > and the HA ends initiate very different numbers of messages, the > Sequence Numbers in the two directions can be very different. In a > case encryption is not used, the Sequence Number MUST be set to 0 > (zero). It seems odd to use sequence numbers only for encrypted packets. What about integrity protected packets? > All > packets that are specific to the Mobile IPv6 protocol and contain a > Mobility Header (as defined in Section 6.1.1. of RFC 6275) SHOULD use > the packet format shown in Figure 7. (This means that some Mobile > IPv6 mobility management messages, such as the HoTI message, as > treated as data packets and using encapsulation described in > Section 6.4). This seems like an inconsistency. HOTI messages are MH messages. Which format do you require for them? Please ciarify. Section 7 seems odd. First, you say that you don't cover the RO part and then you go on explaining nice ideas that could be done. I would replace Section 7 with the following information: - statement that this specification does not change any of the procedures for RO - explanation that tells the reader how the TLS-based HA security model can still support the existing RO procedures (and if it can not... I think you'd have to change your spec... but I don't see why). - identification of possible gaps for future work, such as supporting RO to IPv4 destinations (but we don't support that today, so this isn't the fault of your document). But do not include extra new ideas that could be done (like HAC-based RO). IANA considerations seems to need some material for the attributes used in your new protocol. Who can allocate them, and should there be a registry? Jari |
2011-12-29
|
03 | Jari Arkko | Ballot writeup text changed |
2011-12-29
|
03 | Jari Arkko | State changed to AD Evaluation from Publication Requested. |
2011-11-29
|
03 | 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? This document is being submitted by the authors of the I-D and will be progressed via the AD sponsored process. Jari Arkko (Internet AD) has agreed to be the sponsor of this I-D. The document shepherd for this I-D is : Basavaraj Patil (one of the authors of this I-D). I believe this version of the I-D is ready to be forwarded to the IESG for publication. The I-D has been presented and discussed in the MEXT working group for over 2+ years. (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? The document has been reviewed by several members of the MEXT WG. I do not have any concerns regarding the depth or breadth of the reviews that have been performed so far. (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? I do not believe that the I-D needs further review from a specific area of expertise. However reviews by directorates or experts are welcome. (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. I have no concerns or issues with this document. The I-D has been presented in the MEXT WG and the authors have requested the chairs previously to complete WG last call and progress the I-D and have not received any response from the chairs. In view of the MEXT WG now being rechartered and the AD announcing that some of the WG docs will be progressed via the AD sponsored route, this I-D is now being forwarded as an individual submission sponsored by the AD. There are no known IPR disclosures associated with this I-D. (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 has not been a working group last call for this I-D. Authors have requested this in the past but the chairs have not acted on it. There is general consensus w.r.t the approach proposed by this I-D for standardization on an experimental basis. The MEXT WG as a whole is supportive of standardizing this as an experimental standard. (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. There are no threats of an appeal or extreme discontent with the I-D. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist 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. The I-D has been put through the nits checker. The I-D does not specify any MIBs or media types etc. It meets all the formal review criteria. (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 has split references into normative and informative ones. All the normative references are published RFCs. (1.i) Has the Document Shepherd verified that the document IANA consideration 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 [RFC5226]. 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? The IANA section exists and is consistent with the body of the document. It suggests the creation of a new registry by IANA. (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? The document does not include any XML, BNF rules or MIB definitions that would warrant a check. (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 Mobile IPv6 signaling between a mobile node and its home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/ IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent. Working Group Summary This document has been discussed in the WG over 2+ years and there is general consensus on adopting the proposed solution on an experimental basis. The I-D does not deprecate the IPsec based security mechanism which is the default. Instead it proposes an alternative scheme which enables ease of deployment. Document Quality There is at least one known implementation of the protocol. This implementation has been done on the Nokia N900 device as well as Ubuntu and Debian linux platforms. The implementation has been shown at previous IETF meetings. All reviewers who have helped improve the document have been acknowledged in the I-D. |
2011-11-29
|
03 | Cindy Morgan | Draft added in state Publication Requested |
2011-11-29
|
03 | Cindy Morgan | [Note]: 'Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.' added |
2011-10-11
|
02 | (System) | New version available: draft-ietf-mext-mip6-tls-02.txt |
2011-09-13
|
01 | (System) | New version available: draft-ietf-mext-mip6-tls-01.txt |
2011-09-13
|
03 | (System) | Document has expired |
2011-03-12
|
00 | (System) | New version available: draft-ietf-mext-mip6-tls-00.txt |