Securing Neighbor Discovery Proxy: Problem Statement
RFC 5909
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20
|
04 | (System) | Received changes through RFC Editor sync (changed abstract to 'Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that … Received changes through RFC Editor sync (changed abstract to 'Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages. Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.') |
2017-05-16
|
04 | (System) | Changed document authors from "Suresh Krishnan, Greg Daley" to "Suresh Krishnan, Greg Daley, Jean-Michel Combes" |
2015-10-14
|
04 | (System) | Notify list changed from csi-chairs@ietf.org, draft-ietf-csi-sndp-prob@ietf.org to (None) |
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2010-07-07
|
04 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2010-07-07
|
04 | Amy Vezza | [Note]: 'RFC 5909' added by Amy Vezza |
2010-07-06
|
04 | (System) | RFC published |
2010-03-30
|
04 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-03-30
|
04 | (System) | IANA Action state changed to No IC from In Progress |
2010-03-30
|
04 | (System) | IANA Action state changed to In Progress |
2010-03-30
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-03-30
|
04 | Amy Vezza | IESG has approved the document |
2010-03-30
|
04 | Amy Vezza | Closed "Approve" ballot |
2010-03-30
|
04 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2010-03-25
|
04 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk |
2010-01-23
|
04 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2010-01-22
|
04 | (System) | New version available: draft-ietf-csi-sndp-prob-04.txt |
2009-12-03
|
04 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Stephen Farrell. |
2009-12-03
|
04 | Cindy Morgan | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Cindy Morgan |
2009-12-03
|
04 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-12-03
|
04 | Tim Polk | [Ballot comment] I am not, repeat NOT, a cryptographer, and am not familiar with ring signature schemes, but my quick research on ring signature schemes … [Ballot comment] I am not, repeat NOT, a cryptographer, and am not familiar with ring signature schemes, but my quick research on ring signature schemes came up with descriptions very different from those in section 4.1.3: This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states: In a ring signature, instead of revealing the actual identity of the message signer, it specifies a set of possible signers. The verifier can be convinced that the signature was indeed generated by one of the ring members; however, the verifier is unable to tell which member actually produced the signature. A convertible ring signature scheme allows the real signer to convert a ring signature into an ordinary signature by revealing secret information about the ring signature. These definitions seem in conflict. One of the cryptographers here at NIST noted that both descriptions seem to fall into the "group signature" class of algorithms, but she was not immediately familiar with the term "ring signature" so she couldn't tell me which was the accepted definition. I would strongly encourage you to include a reference for the class of algorithms identified in 4.1.3, since there is some confusion even within the cryptographic community. |
2009-12-03
|
04 | Tim Polk | [Ballot discuss] After sleeping on this, I have changed one issue from a comment to a discuss... specifically, I believe solutions that are based on … [Ballot discuss] After sleeping on this, I have changed one issue from a comment to a discuss... specifically, I believe solutions that are based on group cryptographic algorithms lack the maturity needed for standards track specifications so things described in 4.1.3 would need to be published as Experimental. Accordingly, I believe a new section to the security considerations describing the risks of being on the bleeding edge with cryptography should be added. Where classes of algorithms have had limited scrutiny, there are risks that new attacks will be developed in the future. I think group algorithms are on the bleeding edge, and that makes this class of solutions less attractive than the alternative. |
2009-12-03
|
04 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Discuss from No Objection by Tim Polk |
2009-12-03
|
04 | Jari Arkko | [Ballot comment] Section 2.3 states: The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a method by which multiple link layer segments … [Ballot comment] Section 2.3 states: The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a method by which multiple link layer segments are bridged into a single segment and specifies the IP-layer support that enables bridging under these circumstances. The proxy in this case forwards messages while modifying their source and destination MAC addresses, and rewrites their Link-Layer Address Options, solicited, and override flags. This is a bit misleading. Classic bridging does not require ND proxying at all. However, there are circumstances outlined in RFC 4389 where its desirable to implement ND proxying / ARP proxying instead of classic bridging. I would suggest a small rewrite: The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an alternative method to classic bridging. Just as with classic bridging, multiple link layer segments are bridged into a single segment, but with the help of proxying at IP layer rather than link layer bridging. The proxy in this case forwards messages while modifying their source and destination MAC addresses, and rewrites their Link-Layer Address Options, solicited, and override flags. Section 4.1.2 says: When sending its Binding Update to the HA, the MN would need to provide a certificate containing the subject(proxy-HA)'s public key and address, the issuer(MN)'s CGA and public key, and timestamps indicating when the authority began and when it ends. This certificate would need to be transmitted at binding time, possibly in a Certificate Path Advertisement [RFC3971]. Messaging or such an exchange mechanism would have to be developed. If I have understood correctly, you are suggesting that the MN sends a certificate to the router. If so, CPA seems the wrong message, as it goes from the router to the host per RFC 3971. (Much of the solution space discussion was enlightening, but details like this you could also remove.) |
2009-12-03
|
04 | Jari Arkko | [Ballot discuss] |
2009-12-03
|
04 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Recuse from Discuss by Jari Arkko |
2009-12-03
|
04 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-12-03
|
04 | Jari Arkko | [Ballot discuss] Section 2.3 states: The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a method by which multiple link layer segments … [Ballot discuss] Section 2.3 states: The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a method by which multiple link layer segments are bridged into a single segment and specifies the IP-layer support that enables bridging under these circumstances. The proxy in this case forwards messages while modifying their source and destination MAC addresses, and rewrites their Link-Layer Address Options, solicited, and override flags. This is a bit misleading. Classic bridging does not require ND proxying at all. However, there are circumstances outlined in RFC 4389 where its desirable to implement ND proxying / ARP proxying instead of classic bridging. I would suggest a small rewrite: The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an alternative method to classic bridging. Just as with classic bridging, multiple link layer segments are bridged into a single segment, but with the help of proxying at IP layer rather than link layer bridging. The proxy in this case forwards messages while modifying their source and destination MAC addresses, and rewrites their Link-Layer Address Options, solicited, and override flags. |
2009-12-03
|
04 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2009-12-03
|
(System) | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-csi-sndp-prob-03 | |
2009-12-02
|
04 | Russ Housley | [Ballot comment] Several editorial improvements were suggested in the Gen-ART Review by Vijay Gurbani. Please consider them. > 1) You may want to … [Ballot comment] Several editorial improvements were suggested in the Gen-ART Review by Vijay Gurbani. Please consider them. > 1) You may want to expand SEND before first use in Section 2; > you do so later on (below Figure 1), but should move that up. > > 2) S2.3, below Figure 3: The text says that "An alternative > (alluded to in an appendix of ND Proxy)..." You may want to > provide a reference to the document containing this appendix. > > 3) S3.3: s/options) [RFC4389]/options) [RFC4389]./ |
2009-12-02
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-12-02
|
04 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2009-12-02
|
04 | Tim Polk | [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research on ring signature schemes … [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research on ring signature schemes came up with descriptions very different from those in section 4.1.3: This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states: In a ring signature, instead of revealing the actual identity of the message signer, it specifies a set of possible signers. The verifier can be convinced that the signature was indeed generated by one of the ring members; however, the verifier is unable to tell which member actually produced the signature. A convertible ring signature scheme allows the real signer to convert a ring signature into an ordinary signature by revealing secret information about the ring signature. These definitions seem in conflict. One of the cryptographers here at NIST noted that both descriptions seem to fall into the "group signature" class of algorithms, but she was not immediately familiar with the term "ring signature" so she couldn't tell me which was the accepted definition. I would strongly encourage you to include a reference for the class of algorithms identified in 4.1.3, since there is some confusion even within the cryptographic community. I would also suggest adding a new section to the security considerations describing the risks of being on the bleeding edge with cryptography. Where classes of algorithms have had limited scrutiny, there are risks that new attacks will be developed in the future. |
2009-12-02
|
04 | Tim Polk | [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research describes ring signature schemes … [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research describes ring signature schemes very differently. From section 4.1.3: Specific cryptographic algorithms may help to allow trust between entities of a same group. This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. Applied to SEND, the addresses are cryptographically generated using multiple public keys and the Neighbor Discovery messages are signed with an RSA ring signature. The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states: In a ring signature, instead of revealing the actual identity of the message signer, it specifies a set of possible signers. The verifier can be convinced that the signature was indeed generated by one of the ring members; however, the verifier is unable to tell which member actually produced the signature. A convertible ring signature scheme allows the real signer to convert a ring signature into an ordinary signature by revealing secret information about the ring signature. These definitions seem in conflict, but the class of algorithms seem to meet the stated goal... |
2009-12-02
|
04 | Tim Polk | [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research describes ring signature schemes … [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research describes ring signature schemes very differently. From section 4.1.3: Specific cryptographic algorithms may help to allow trust between entities of a same group. This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. Applied to SEND, the addresses are cryptographically generated using multiple public keys and the Neighbor Discovery messages are signed with an RSA ring signature. The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states: In a ring signature, instead of revealing the actual identity of the message signer, it specifies a set of possible signers. The verifier can be convinced that the signature was indeed generated by one of the ring members; however, the verifier is unable to tell which member actually produced the signature. A convertible ring signature scheme allows the real signer to convert a ring signature into an ordinary signature by revealing secret information about the ring signature. These definitions seem in conflict, but the class of algorithms seem to meet the stated goal... |
2009-12-02
|
04 | Tim Polk | [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research describes ring signature schemes … [Ballot comment] I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but my quick research describes ring signature schemes very differently. From section 4.1.3: Specific cryptographic algorithms may help to allow trust between entities of a same group. This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. Applied to SEND, the addresses are cryptographically generated using multiple public keys and the Neighbor Discovery messages are signed with an RSA ring signature. The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states: In a ring signature, instead of revealing the actual identity of the message signer, it specifies a set of possible signers. The verifier can be convinced that the signature was indeed generated by one of the ring members; however, the verifier is unable to tell which member actually produced the signature. A convertible ring signature scheme allows the real signer to convert a ring signature into an ordinary signature by revealing secret information about the ring signature. These definitions seem in conflict, but the class of algorithms seem to meet the stated goal... |
2009-12-02
|
04 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-12-02
|
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-12-02
|
04 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-12-02
|
04 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2009-12-02
|
04 | Ralph Droms | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms |
2009-12-02
|
04 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-12-02
|
04 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-12-01
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-12-01
|
04 | Adrian Farrel | [Ballot comment] Section 5 The previous part of this document focused on the case where two nodes defend the same address (i.e. the … [Ballot comment] Section 5 The previous part of this document focused on the case where two nodes defend the same address (i.e. the node and the proxy). But, there are scenarios where two or more nodes are defending the same address. I read this a couple of times and it doesn't compute :-) Firstly I suggest you insert a reference in place of "the previous part of this document". Secondly: can you resolve the "But"? The second sentence seems to say, "but the first sentence is true"! --- A petty nit... Would you consider changing the title to... Problem Statement for Securing Neighbor Discovery Proxy ...or... Securing Neighbor Discovery Proxy : Problem Statement ...to add a little clarity. |
2009-12-01
|
04 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-csi-sndp-prob-03, and have a couple of questions/concerns that I'd like to discuss before recommending approval of the document: - … [Ballot discuss] I have reviewed draft-ietf-csi-sndp-prob-03, and have a couple of questions/concerns that I'd like to discuss before recommending approval of the document: - I think the text about IKEv2 (Section 2.2) is quite misleading. As far as I know, in most security gateway deployments the gateway has a block of addresses, and "intercepting" packets sent to this block is handled by routing (static routes or intra-AS routing protocol), not by ND/ARP messages. It's not totally impossible that the approach described in Section 2.2 could be used, but IMHO it would be rare. - For Mobile IPv6, I guess we don't really have deployments, but are there any SDOs that are even considering deployments where one MN would *ever* see ND queries from another MN, even if both are at home? (AFAIK in most other SDO specs, every MN gets a full IPv6 prefix, so securing NS/NA is not really an issue -- and RS/RA is handled by security the point-to-point link to the router.) From Stephen Farrell's SecDir review: - Section 4.2.6: I think current best practices usually avoid increasing certificate serial numbers (and use random-looking serial numbers instead). I'd suggest either deleting that if its felt to be unlikely used, or else, if its actually likely to be used, then documenting how it could actually work - In Section 7.2, I would strongly recommend deleting the word "non-repudiable" (or alternatively, explaining what is meant by the term in this context -- it's very overloaded term.) |
2009-12-01
|
04 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2009-11-23
|
04 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-11-20
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2009-11-20
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2009-11-18
|
04 | Amy Vezza | Last call sent |
2009-11-18
|
04 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-11-17
|
04 | Ralph Droms | Telechat date was changed to 2009-12-03 from 2009-11-19 by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | Last Call was requested by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | Placed on agenda for telechat - 2009-11-19 by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | State Changes to Last Call Requested from AD Evaluation by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | State Changes to AD Evaluation from Publication Requested by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | [Note]: 'The document shepherd is Marcelo Bagnulo (marcelo@it.uc3m.es)' added by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2009-11-17
|
04 | Ralph Droms | Ballot has been issued by Ralph Droms |
2009-11-17
|
04 | Ralph Droms | Created "Approve" ballot |
2009-11-17
|
04 | (System) | Ballot writeup text was added |
2009-11-17
|
04 | (System) | Last call text was added |
2009-11-17
|
04 | (System) | Ballot approval text was added |
2009-10-19
|
04 | Amy Vezza | Document Shepherd Write-up fordraft-ietf-csi-sndp-prob-02 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed … Document Shepherd Write-up fordraft-ietf-csi-sndp-prob-02 (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? The document shepherd is Marcelo Bagnulo who has reviewed this version of the document and believes that us 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? The document has been reviewed by 6 reviewers and the reviews were thorough. We issues 2 WGLC. During the first one, we received the reviews and during the second one, nobody objected. (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? No. (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 special concerns or issues. The document is an informational document describing the problem and the solution space. (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? The document describes one of the main problems the CSI is chartered to work on. The understanding of the problem by the WG is good and this is reflected in the 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 conflicts. (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. I have verified the ID nits. There a couple of references that need updating (already informed the authors) and there is no disclaimer for pre-RFC5378 work, but i don't think it is needed in this case. No MIB Doctor, media type nor UR type reviews are needed for this document. The document intended status is informational. (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 references are split into normative and informative. All normative references are in RFC state. The is no downward dependency, since this is an informational 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 document has a IANA considerations section, but there is no IANA action required. No protocol extensions are required No new registry is created. (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 no contain any section written in a formal language. (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. Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform neighbor discovery operations on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor discovery messages. Neighbor Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to Secured Neighbor Discovery. 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? Nothing special that worth noting. Not a controversial document. 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? The document is an informational problem statement. The problem described in one of the main issues the CSI is chartered to work on. There is already a WG document describing a proposed solution to the problem. The document had 5 through reviews, including reviews from Julien Laganier, Sheng Jiang, Tony Cheneau and no substantive issues were identified. 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: Marcelo Bagnulo Area Director: Ralf Droms |
2009-10-19
|
04 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2009-10-19
|
04 | Amy Vezza | [Note]: 'The document shepherd is Marcelo Bagnulo (marcelo@it.uc3m.es)' added by Amy Vezza |
2009-10-18
|
03 | (System) | New version available: draft-ietf-csi-sndp-prob-03.txt |
2009-10-17
|
02 | (System) | New version available: draft-ietf-csi-sndp-prob-02.txt |
2009-09-09
|
04 | (System) | Document has expired |
2009-03-09
|
01 | (System) | New version available: draft-ietf-csi-sndp-prob-01.txt |
2008-10-20
|
00 | (System) | New version available: draft-ietf-csi-sndp-prob-00.txt |