Hi Roni, Sorry for my late reply.
I think I'm fine with your proposed text. I've seen that you have updated DRR. Nnce you update RPR draft, I'll review both documents again and post any further comments that I have (if any), as part of my shepherd review. Thanks, Carlos On Sat, 2013-03-30 at 10:46 +0300, Roni Even wrote: > 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
