Re: [P2PSIP] Review of DRR and RPR documents

[Carlos Jesús Bernardos Cano <[e-mail]>]

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 '[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
> > >
> > 
>