OK, thanks. Carlos
On Wed, 2013-04-10 at 01:07 +0000, Zongning wrote: > 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
