Subject: Re: [P2PSIP] Review of DRR and RPR documents

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 10 Apr 2013 03:00:40 +0200

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-masked] [mailto:[email-masked]] On Behalf Of Carlos Jes?s Bernardos Cano
> Sent: 22 January, 2013 1:51 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
>

---

From: Zongning <[email-masked]>
Date: Wed, 10 Apr 2013 01:07:42 +0000

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-masked]' to do manual post and hope to see RPR draft in IETF repository soon.
Sorry about that.

-Ning

> From: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2013 9:01 AM
> To: Roni Even
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [P2PSIP] Review of DRR and RPR documents
> 
> Hi Roni,
> 
> Sorry for my late reply.
> 
> > "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.
> >
> >
> > "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
> >
> >
> > 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
> >
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 10 Apr 2013 03:15:02 +0200

OK, thanks.

Carlos