Re: [P2PSIP] Review of DRR and RPR documents

[Zongning <[e-mail]>]

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 '[e-mail]' 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:[e-mail]]
> Sent: Wednesday, April 10, 2013 9:01 AM
> To: Roni Even
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Carlos Jes?s Bernardos Cano
> > Sent: 22 January, 2013 1:51 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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
> >
>