Hi Carlos, The current text in the security section of both drafts is "As a routing alternative, the security part of RPR conforms to section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security."
I saw you comment "I think this sections has to be extended. It is not clear to me how the proposed approach conforms to -base security without providing more details. How DoS attachs would be avoided for example, by trying to forge the destination address". I am not sure what we can add here. The security section of the base draft starts with an overview that references RFC5765. DRR and RPR are only adding routing options. DRR provides a direct path back to the source and as such reduce the problem on malicious nodes on the route to affect the route back. The digital signatures defined in the based draft protects against changes of the forwarding header. RPR as specified in the draft (section3.2) is using a trusted node close to the initiating node, using a trusted nodes is recommended as a security policy. We can look at RPR as DRR in the direction toward the destination and since it is not an arbitrary node in the middle but one that should be trusted (managed network, bootstrap peers or configured relay) and using the based security recommendation will suffice. We can try to add more text based on the above observation for DRR "As a routing alternative, the security part of DRR conforms to section 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security. The DRR routing option provide the information about the route back to the source. According to section 13 of the base drat the forwarding header MUST be digitally signed protecting the DRR routing information." For RPR "As a routing alternative, the security part of RPR conforms to section 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security. RPR behave like a DRR requesting node towards the destination node. The RPR relay node is not an arbitrary node but should be a trusted one (managed network, bootstrap peers or configured relay) which will make it less of a risk as outlined in section13 of the based draft." Thanks Roni Even -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carlos Jes?s Bernardos Cano Sent: 22 January, 2013 1:51 PM To: [email protected] Cc: [email protected]; [email protected] Subject: [P2PSIP] Review of DRR and RPR documents Hi, As agreed during the last meeting, I've performed a review of draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipping them to the IESG for publication. My reviews are attached to this e-mail (I added comments to the PDF version of each draft, hope this is fine). I'd like authors to go through the comments before sending the documents to the IESG. There might be some issues that need to be brought to the WG for discussion. I'd also like to ask the WG for opinion on one particular aspect. I'm wondering if it would be better to merge both documents into a single one. Currently, both documents make quite a lot of cross-references, but still there is duplicate text in both of them, so I'd be more in favor of merging (personal opinion). Please, comment on this on the mailing list. Thanks, Carlos _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
