headers
Bob Briscoe | 3 May 2009 13:17
Picon

Re: IETF74 TSVWG Minutes posted

Lars, James,

I read the latest groupkeying draft before replying the other day on 
the query I raised. Pls consider that a full review with only one 
outstanding issue - as explained in my posting last week.

Bob

At 05:54 30/04/2009, Francois Le Faucheur IMAP wrote:
>Hello James, Lars,
>
>Regarding:
>"
>*  Francois- Applicability of Keying Methods for RSVP Security
>    draft-ietf-tsvwg-rsvp-security-groupkeying
>1315-1325 (10 min)
>"
>...
>
>1)
>"
>Lars: Francois needs to lobby folks to review doc before there can be
>a WGLC
>"
>I understood Lars was also going to drop a note on the list to call
>for review volunteer. Can you do this?
>
>2)
>"
>     - who volunteers to review it? (no hands)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Briscoe | 3 May 2009 13:37
Picon

Re: IETF74 TSVWG Minutes posted

James,

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
*  Bob's - Layered Encapsulation of Congestion 
Notification  1410-1420 (10 min) 4 draft-ietf-tsvwg-ecn-tunnel
...
Fred - there's an RFC that talks about tunnels (inner part and outer
        part), is this covering the same thing?
Bob - no, this is addressing what RFC4301 left out (on purpose?)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
I haven't checked the audio transcript, but I doubt I said this last 
bit. Probably more like:

"Bob - no, this is bringing non-IPsec tunnels into line with what 
RFC4301 added, and addressing what RFC4301 left out."

Whatever, pls scrub the text "(on purpose?)".

I'm unlikely to have conjectured that RFC4301 left this out on 
purpose. That makes it sound like the Sec Area might actively oppose 
the tidy-ups that I'm proposing. I've tried hard to ensure the Sec 
Area can't complain about what I'm proposing. I believe the issues 
I'm raising were just not even considered when they did the new IPsec 
architecture.

Bob

At 23:27 29/04/2009, James M. Polk wrote:
>Please see the page at the following link for our TSVWG minutes
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
James M. Polk | 4 May 2009 19:52
Picon
Favicon

Re: IETF74 TSVWG Minutes posted

Bob

ack

Thanks for checking this

James

At 06:37 AM 5/3/2009, Bob Briscoe wrote:
>James,
>
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>*  Bob's - Layered Encapsulation of Congestion 
>Notification  1410-1420 (10 min) 4 draft-ietf-tsvwg-ecn-tunnel
>...
>Fred - there's an RFC that talks about tunnels (inner part and outer
>        part), is this covering the same thing?
>Bob - no, this is addressing what RFC4301 left out (on purpose?)
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>I haven't checked the audio transcript, but I doubt I said this last 
>bit. Probably more like:
>
>"Bob - no, this is bringing non-IPsec tunnels into line with what 
>RFC4301 added, and addressing what RFC4301 left out."
>
>Whatever, pls scrub the text "(on purpose?)".
>
>I'm unlikely to have conjectured that RFC4301 left this out on 
>purpose. That makes it sound like the Sec Area might actively oppose 
>the tidy-ups that I'm proposing. I've tried hard to ensure the Sec
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 May 2009 01:30
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: RSVP Extensions for Path-Triggered RSVP Receiver Proxy
	Author(s)	: F. Le Faucheur, H. Malik, J. Manner, A. Narayanan, A. Guillou, L. Faucheur
	Filename	: draft-ietf-tsvwg-rsvp-proxy-proto-09.txt
	Pages		: 33
	Date		: 2009-5-4
	
RSVP signaling can be used to make end-to-end resource reservations
   in an IP network in order to guarantee the QoS required by certain
   flows.  With conventional RSVP, both the data sender and receiver of
   a given flow take part in RSVP signaling.  Yet, there are many use
   cases where resource reservation is required, but the receiver, the
   sender, or both, is not RSVP-capable.  Where the receiver is not
   RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
   thereby performing RSVP signaling on behalf of the receiver.  This
   allows resource reservations to be established on the segment of the
   end-to-end path from the sender to the RSVP Receiver Proxy.  However,
   as discussed in the companion document presenting RSVP Proxy
   approaches, RSVP extensions are needed to facilitate operations with
   an RSVP Receiver Proxy whose signaling is triggered by receipt of
   RSVP Path messages from the sender.  This document specifies these
   extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-09.txt

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Weis | 6 May 2009 01:38
Picon
Favicon

Re: IETF74 TSVWG Minutes posted

Hi Lars & James,

I've reviewed the latest groupkeying draft, and consider it to be  
ready for WGLC. I have only one minor comment on the document (which I  
will post separately).

Brian

On May 3, 2009, at 4:17 AM, Bob Briscoe wrote:

> Lars, James,
>
> I read the latest groupkeying draft before replying the other day on  
> the query I raised. Pls consider that a full review with only one  
> outstanding issue - as explained in my posting last week.
>
>
> Bob
>
> At 05:54 30/04/2009, Francois Le Faucheur IMAP wrote:
>> Hello James, Lars,
>>
>> Regarding:
>> "
>> *  Francois- Applicability of Keying Methods for RSVP Security
>>   draft-ietf-tsvwg-rsvp-security-groupkeying
>> 1315-1325 (10 min)
>> "
>> ...
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Weis | 6 May 2009 01:49
Picon
Favicon

Review of draft-ietf-tsvwg-rsvp-security-groupkeying-04

Hi Francois & Michael,

I have reviewed this document and have only one comment. Section 2  
discussed "implicit" and "explicit" trust. Generally, I agree with it  
except for the following sentence:

"Note that in any group keying scheme like GDOI a node trusts  
explicitly as well as implicitly all the other members of the group."

I don't see where the fact that multiple parties hold the same key to  
make the trust explicit. For example, when manual keying is used the  
node doesn't really have any idea how many other nodes share that key  
(i.e., whether it is a pairwise or group key). It simply sends and  
receives RSVP messages and explicitly trusts the next RSVP node to  
handle the message to do the right thing, regardless of whether its  
identity is known or unknown. Non-neighbors are always trusted  
implicitly whether or not they happen to share a key.

Were you thinking of some other attribute of group keying that makes  
the trust explicit?

Thanks,
Brian

--

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew <at> cisco.com
(Continue reading)

Permalink | Reply | 9 comments |
headers
Lars Eggert | 6 May 2009 15:37
Picon
Gravatar

Re: WGLC for Port Randomization starts now (April 1st)

Hi, authors,

On 2009-4-15, at 17:55, Eggert Lars (Nokia-NRC/Espoo) wrote:
> Authors, please discuss this review with Mark. The chairs think that  
> eventually, a document revision will be needed to address the points  
> that Mark has raised.

please begin the discussion of the WG last call comments, so that a  
final revision can be produced that we can move forward to IETF last  
call.

Thanks,
Lars

> On 2009-4-15, at 6:33, Mark Allman wrote:
>>
>>> This is the start of the WGLC for Port Randomization, which will
>>> last for 14 days - starting April 1st, going through April
>>> 15th. Please review this document and post comments to the TSVWG
>>> list and authors.
>>
>> I read the document today.  Comments:
>>
>> - The title is bogus.  The prose carefully says that the document is
>>   not about port randomization, but about port obfuscation.  The  
>> title
>>   should be corrected.
>>
>> - While the early part of the document does talk in terms of
>>   obfuscation and not randomization the entire document needs
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 8 May 2009 01:35
Picon
Favicon

Re: WGLC for Port Randomization starts now (April 1st)


Some comments on Mark's comments...

Mark Allman wrote:
>> This is the start of the WGLC for Port Randomization, which will
>> last for 14 days - starting April 1st, going through April
>> 15th. Please review this document and post comments to the TSVWG
>> list and authors.
> 
> I read the document today.  Comments:
> 
...
>   - Section 2.1: There is a claim that the ephemeral port space is
>     "traditionally" from 49152-65535.  I think it is more traditional
>     for hosts to use monotonically increasing ports starting at 1024.
>     Even if hosts do use this upper range they also use this lower range
>     a bunch.  I'd nuke this statement as probably wrong, but at least
>     dubious.

"traditionally" is incorrect; it's *defined* as that range by IANA.

Source ports can use any port they want, though - as Mark points out -
they tend to avoid the "system" ports.

>   - In 2.3 you might note that an alternative approach is for both hosts
>     to keep state about recent connections.  I am not arguing it is a
>     good approach or a bad approach...just an alternate approach that
>     would work towards minimizing the collision rate.

And, FWIW, some of that state is already being kept, e.g., in TIME-WAIT
(Continue reading)

Permalink | Reply | 54 comments |
headers
Lars Eggert | 11 May 2009 17:43
Picon
Gravatar

Fwd: WGLC for Port Randomization starts now (April 1st)

Forwarded with permission. Discussion is at http://thread.gmane.org/gmane.linux.network/127652/focus=127679

Begin forwarded message:

> From: Stephen Hemminger <shemminger <at> linux-foundation.org>
> Date: May 10, 2009 1:50:40 GMT+03:00
> To: "James M. Polk" <jmpolk <at> cisco.com>,         "Eggert Lars (Nokia- 
> NRC/Espoo)" 	<lars.eggert <at> nokia.com>
> Subject: Re: WGLC for Port Randomization starts now (April 1st)
>
> One issue with port randomization which is not covered in the draft,  
> but
> just showed up as a surprise to a Linux user is that port  
> randomization
> increases the frequency of port reuse (see Birthday Paradox).  For  
> correctly
> behaving endpoints, this no problem. But in this user's case there  
> was some
> old firewall (non-conforming middlebox), that rejected the new  
> connections.
> It is another case of a new protocol change breaks assumptions made  
> by intermediate
> devices.
>
> --
Attachment (smime.p7s): application/pkcs7-signature, 2446 bytes
Permalink | Reply | 3 comments |
headers
Anantha Ramaiah (ananth | 11 May 2009 18:03
Picon
Favicon

Re: Fwd: WGLC for Port Randomization starts now (April 1st)


FWIW, the expired draft ( we were supposed re-submit it after collecting
data, but we haven't done that yet) 

http://ietfreport.isoc.org/all-ids/draft-ananth-tsvwg-timewait-00.txt

does talk about this "birthday paradox" issue. In particular it talks
about the issue which we observed on field after changing the port
allocation to random from sequential. (when the peer TCB was in the
TIMEWAIT state). The non-confirming middle boxes is another thing which
could cause side-effects, we had observed some cases in the past, but
can't re-collect the exact nature and symptoms.

-Anantha

> -----Original Message-----
> From: tsvwg-bounces <at> ietf.org [mailto:tsvwg-bounces <at> ietf.org] 
> On Behalf Of Lars Eggert
> Sent: Monday, May 11, 2009 8:43 AM
> To: tsvwg
> Cc: Stephen Hemminger
> Subject: [Tsvwg] Fwd: WGLC for Port Randomization starts now 
> (April 1st)
> 
> Forwarded with permission. Discussion is at 
> http://thread.gmane.org/gmane.linux.network/127652/focus=127679
> 
> Begin forwarded message:
> 
> > From: Stephen Hemminger <shemminger <at> linux-foundation.org>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane