Subject: [P2PSIP] New RELOAD Draft

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Jul 2008 14:36:13 -0700

Folks,

What with the short time frame and there not being an editor
yet, the RELOAD author team made a final pass through the
document to have something to discuss in Dublin. We recognize
that none of these changes were vetted by the WG, so we'll
of course back any of them out that people object to. A summary
appears below:

- Changed it to have a draft-ietf- name
- Changed "Connect" to Attach"
- Added some text to make the first node work properly
- Restricted the number of node-ids in a certificate to
  one. 
- Added an options block to the forwarding header
- Clarified handling of replayed messages.

There are also a nunber of known open issues, which we'll
be starting threads on shortly.

Until the draft appears in the repository, you can find it at:

https://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-p2psip-reload.txt

Thanks,
-Ekr

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Song Haibin <[email-masked]>
Date: Tue, 15 Jul 2008 14:27:34 +0800

Hi All,

The p2psip security requirements draft version 03 represents an initial
merge of two drafts:
   draft-matuszewski-p2psip-security-requirements-02
   draft-song-p2psip-security-eval-00

It is submitted to continue the ongoing dialogue within the P2PSIP Working
Group around security with the recognition that further work needs to be
done to complete the merger of the two documents, comments are very
definitely welcome on this -03 version.

The draft can be found at:
http://www3.ietf.org/proceedings/staging/draft-matuszewski-p2psip-security-r
equirements-03.txt

Best Regards,
Song Haibin
Email: [email-masked]
Skype: alexsonghw

---

From: "Dan York" <[email-masked]>
Date: Tue, 15 Jul 2008 17:11:59 +0000

FYI, the URL for this draft is now:

http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-requirements-03.txt

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

-----Original Message-----
From: Song Haibin <[email-masked]>

Date: Tue, 15 Jul 2008 14:27:34 
To: 'P2PSIP Mailing List'<[email-masked]>
Subject: [P2PSIP] Merged draft on P2PSIP Security

Hi All,

Best Regards,
Song Haibin

---

From: Michael Chen <[email-masked]>
Date: Wed, 23 Jul 2008 21:56:33 -0800

Eric,

Here are some notes I have accumulated so far for the July draft:

A) Section 6.2.1 should add "network byte-order" to the "idiosyncrasies" 
of the language.

B) In 6.2.2, the 'relo_token' 32-bit value should be 0xD2454c4f not 
0xC2454c4f.

C) In 6.2.2, the description for 'var_list_length' should be 
"...following THREE length fields..."

D) In 6.2.3.1, the description for 'error_info' says "This MUST be empty 
(zero length)
     except as specified below."  However, nothing in "below" explicitly 
mention being used
     in 'error_info'.

E) In 6.2.2.2, "ROUTE-LOG-RESPONSE" should be RESPONSE-ROUTE-LOG per 6.2.2.

F) Section 6.4.2.1.1 must clarify whether the ICE candidate string is 
with or without
     the prefix "candidate:" as defined in draft-ietf-mmusic-ice-19 
section 15.1.

G) Suggestion: In Forwarding Header (6.2.2), move the 'overlay' or 
'transaction_id' fields
     next to each other, so that when computing the signature, both 
fields can be fed to the
     signing function in a single block instead of two separate ones.

Thanks

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Jul 2008 22:34:00 -0700

Thanks for the comments.

At Wed, 23 Jul 2008 21:56:33 -0800,
> A) Section 6.2.1 should add "network byte-order" to the "idiosyncrasies" 

Fair enough, though of course this is how almost everything in IETF
is done.

> B) In 6.2.2, the 'relo_token' 32-bit value should be 0xD2454c4f not 

Thanks.

>      except as specified below."  However, nothing in "below" explicitly 

It's *far* below. I'll fix.

>      the prefix "candidate:" as defined in draft-ietf-mmusic-ice-19 

Right. I suspect we'll want replace this with a new encoding....

>      signing function in a single block instead of two separate ones.

This doesn't add a lot of performance value as compared to the
hashing and digital signing.

-Ekr