headers
Wei Yongjun | 3 Mar 2010 08:08
Favicon

Question about SCTP AUTH information structure (SCTP_AUTHINFO)


Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit

Hi all:

The draft-ietf-tsvwg-sctpsocket-21.txt include the following test:

5.2.8.  SCTP AUTH Information Structure (SCTP_AUTHINFO)

   This cmsghdr structure specifies SCTP options for sendmsg().

          +--------------+---------------+----------------------+
          | cmsg_level   | cmsg_type     | cmsg_data[]          |
          +--------------+---------------+----------------------+
          | IPPROTO_SCTP | SCTP_AUTHINFO | struct sctp_authinfo |
          +--------------+---------------+----------------------+

   Here is the definition of the sctp_authinfo structure:

   struct sctp_authinfo {
     uint16_t auth_keyid;
   };

   auth_keyid:  This specifies the shared key identifier used for
      sending the user message.

   An sctp_authinfo item always corresponds to the data in msg_iov.

What is the action when the user DATA chunk be bundled with other
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gorry Fairhurst | 3 Mar 2010 10:25
Picon
Picon

Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)


I'll just respond on RTP here...

On 03/03/2010 05:04, Fernando Gont wrote:

<snip>

>
>> (2)  Abstract, last sentence
>>
>> The new elaborations on RTP seem to be inappropriate.
>> RTP isn't a "classical" transport protocol.
>> RFC 3550 says (Section 11, 2nd para):
>>
>>   "RTP relies on the underlying protocol(s) to provide demultiplexing of
>>    RTP data and RTCP control streams.  For UDP and similar protocols, ..."
> [...]
>>
>> Therefore, I suggest to drop the clause on RTP entirely:
>
> FWIW, Dan Wing suggested this as one of the possible ways forward for
> the RTP issue. So unless anybody disagrees I will apply your prosed change.
>
>

To me, it would seem OK to see RTP removed from the Abstract.

I would though very much prefer to see it still described in the draft, 
since it is an example of an important transport "layer" that is 
impacted by the methods described in the draft. You may like to think
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 3 Mar 2010 22:32
Picon
Picon

Comments on draft-ietf-tsvwg-ecn-tunnel-07

Bob, WG,

I've completed a review of the above draft, with a view to starting a 
WGLC. I have some comments, please see below, and have contacted Bob to 
see if he can make a new revision.

Best wishes,

Gorry Fairhurst

----------------------------------------------------------------------------
Issues:

---
1)
634 be followed.  However, alternate ECN tunnelling schemes are NOT
635 RECOMMENDED as the deployment burden of handling exceptional PHBs in

- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is 
not defined in RFC 2119.  If it is intended as a requirements 
expression, it should be rewritten using one of the combinations defined 
in RFC 2119; otherwise it should not be all-uppercase.
- I wonder if this may be written /SHOULD NOT be.../?
---
2)
741 Alarms should be rate-limited so that the anomalous combinations
            ^^^^^^
- Is this a place where the IETF should make a strong requirements 
recommendation, and use /SHOULD/?
---
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Briscoe | 4 Mar 2010 11:02
Picon

Re: Comments on draft-ietf-tsvwg-ecn-tunnel-07

Gorry,

Thanks for this careful (as always) review.

I've dealt with all your points, responding to 
some where necessary inline. The new draft was 
posted yesterday as draft-ietf-tsvwg-ecn-tunnel-08.

Here's a summary of the changes made as a 
consequence (I omitted to add this text to the 
change log within the doc - if it goes to another draft, I will add it):

 From ietf-07 to ietf-08:

       *  Changes to standards actions:

          +  Section 4: Changed non-RFC2119 phrase 'NOT RECOMMENDED' to
             'SHOULD be avoided', wrt alternate ECN tunnelling schemes.

          +  Section 4.2: Used upper-case in 'Alarms SHOULD be rate-
             limited'.

          +  Section 7: Made bullet #1 in the decapsulation guidelines
             for alternate schemes more precise.  Also changed any upper-
             case keywords in this informative section to lower case.

       *  Editorial changes:

          +  Changed copyright notice to allow for pre-5378 material.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Stewart | 5 Mar 2010 13:34

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

Yongjun-san

I believe when you send with this option you are changing the
key number that you are using. So any new chunks sent at that
point that are auth'd are now using the new key. If each
send specified a different key you would end up with the maybe the last
key as the active one.

At least that is my guess.. Michael?

R
On Mar 2, 2010, at 11:08 PM, Wei Yongjun wrote:

>
> Content-Type: text/plain; charset=GB2312
> Content-Transfer-Encoding: 7bit
>
> Hi all:
>
>
> The draft-ietf-tsvwg-sctpsocket-21.txt include the following test:
>
> 5.2.8.  SCTP AUTH Information Structure (SCTP_AUTHINFO)
>
>   This cmsghdr structure specifies SCTP options for sendmsg().
>
>          +--------------+---------------+----------------------+
>          | cmsg_level   | cmsg_type     | cmsg_data[]          |
>          +--------------+---------------+----------------------+
>          | IPPROTO_SCTP | SCTP_AUTHINFO | struct sctp_authinfo |
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Tuexen | 5 Mar 2010 13:41
Picon

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

On Mar 5, 2010, at 1:34 PM, Randy Stewart wrote:

> Yongjun-san
> 
> I believe when you send with this option you are changing the
> key number that you are using. So any new chunks sent at that
> point that are auth'd are now using the new key. If each
NO. it only allies to the message you sent down.
> send specified a different key you would end up with the maybe the last
> key as the active one.
> 
> At least that is my guess.. Michael?
When you use the SCTP_AUTHINFO it does only apply to the message
you are currently sending. When you want to change the "default",
you use the SCTP_AUTH_ACTIVE_KEY socket option.

Best regards
Michael
> 
> R
> On Mar 2, 2010, at 11:08 PM, Wei Yongjun wrote:
> 
>> 
>> Content-Type: text/plain; charset=GB2312
>> Content-Transfer-Encoding: 7bit
>> 
>> Hi all:
>> 
>> 
>> The draft-ietf-tsvwg-sctpsocket-21.txt include the following test:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Randy Stewart | 5 Mar 2010 14:03

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

Hmm.. having not paid much attention to that section of
the text ;-)

So when I send down a key with a message only that message
gets the key... interesting... Is this useful for some reason?

I mean why not just change the key??

R
On Mar 5, 2010, at 4:41 AM, Michael Tuexen wrote:

> On Mar 5, 2010, at 1:34 PM, Randy Stewart wrote:
>
>> Yongjun-san
>>
>> I believe when you send with this option you are changing the
>> key number that you are using. So any new chunks sent at that
>> point that are auth'd are now using the new key. If each
> NO. it only allies to the message you sent down.
>> send specified a different key you would end up with the maybe the  
>> last
>> key as the active one.
>>
>> At least that is my guess.. Michael?
> When you use the SCTP_AUTHINFO it does only apply to the message
> you are currently sending. When you want to change the "default",
> you use the SCTP_AUTH_ACTIVE_KEY socket option.
>
> Best regards
> Michael
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Tuexen | 5 Mar 2010 14:41
Picon

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

On Mar 5, 2010, at 2:03 PM, Randy Stewart wrote:

> Hmm.. having not paid much attention to that section of
> the text ;-)
> 
> So when I send down a key with a message only that message
> gets the key... interesting... Is this useful for some reason?
The key is something specific to the user message. You can
use a default or a specific value. Like the PPID, where you
can provide a CMSG or set the default. For DTLS we only have
on key (sendingwise) at a time, but the API is generic.
> 
> I mean why not just change the key??
Then you need
getsockopt(old_key);
if (oldkey != newkey)
	setsockopt(new_key);
send();
if (oldkey!=newkey)
	setsockopt(oldkey);
However, this breaks when you have multiple threads. So having
a way to do this atomically with the send call is the right
way, I think.

Best regards
Michael
> 
> R
> On Mar 5, 2010, at 4:41 AM, Michael Tuexen wrote:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 5 Mar 2010 19:33
Favicon

Re: Question about SCTP AUTH information structure (SCTP_AUTHINFO)

Michael,

Michael Tuexen wrote:                       (Fri, 05 Mar 2010 14:41:07)
> > 
> > I mean why not just change the key??
> Then you need
> getsockopt(old_key);
> if (oldkey != newkey)
> 	setsockopt(new_key);
> send();
> if (oldkey!=newkey)
> 	setsockopt(oldkey);
> However, this breaks when you have multiple threads. So having
> a way to do this atomically with the send call is the right
> way, I think.

Why not just use sendmsg() with newkey
as ancillary data?

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 0 comments |
headers
Michael Tüxen | 7 Mar 2010 11:11
Picon

Re: Start of WGLC for Datagram Transport Layer Security for Stream Control Transmission Protocol

Dear all,

I would like to make two comments:

* The name EXTRACTOR_DTLS_OVER_SCTP in section 5 should be changed to EXPORTER_DTLS_OVER_SCTP.
  Reason: The TLS exporter RFC-to-be changed this, however some other documents still registered
  the name with the EXTRACTOR prefix.
* We possibly should change in section 4.7 from
  The exporter MUST use the label given in Section 5 and an empty context.
  to
  The exporter MUST use the label given in Section 5 and no context.
  Reason: This would make the usage of the TLS extractor clear and addresses a change
  in the TLS extractor RFC-to-be currently being discussed.

Best regards
Michael

On Feb 26, 2010, at 1:41 PM, Gorry Fairhurst wrote:

> 
> This email announces the beginning of a working group last call for
> draft-ietf-tsvwg-dtls-for-sctp-04.txt, "Datagram Transport Layer Security for Stream Control
Transmission Protocol". This document is now thought by the authors to be ready to proceed to be published
as a Proposed Standard. Please send any comments to the TSVWG list.
> 
> The draft is available at:
> http://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp-04.txt
> 
> The document will  be forwarded in parallel to the Security Directorate for a Security Review.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane