Hi, Carlos, I made mistake (using wrong file) when I tried to submit RPR draft, so that I could not do automatic post via IETF portal. I have asked '[email protected]' to do manual post and hope to see RPR draft in IETF repository soon. Sorry about that.
-Ning > -----Original Message----- > From: Carlos Jesús Bernardos Cano [mailto:[email protected]] > Sent: Wednesday, April 10, 2013 9:01 AM > To: Roni Even > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: [P2PSIP] Review of DRR and RPR documents > > 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
