Request to publish draft-ietf-tsvwg-ecn-tunnel-08 by the TSVWG.

This note includes a request to publish a document by the TSVWG to the 
TSV ADs. The current version of this document is:

http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-tunnel-08

Thanks to all who participated in reviewing and contributing text to 
this draft!

Best wishes,

Gorry Fairhurst

----

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

This version is dated September 17, 2008.

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

Gorry Fairhurst, TSVWG Chair

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

Request to publish draft-ietf-tsvwg-dtls-for-sctp-05.txt by the TSVWG.

This note includes a request to publish a document by the TSVWG to the
TSV ADs. The current version of this document is at:
http://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp-05

Thanks to all who participated in reviewing and contributing the text
that finally formed this draft!

Best wishes,

Gorry Fairhurst

----

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

This version is dated September 17, 2008.

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

Gorry Fairhurst, TSVWG Chair

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

secdir review for draft-ietf-tsvwg-ecn-tunnel-08

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other comments.

This document describes revised, consistent semantics for setting
the ECN (Explicit Congestion Notification) field in the IP header
on entry to and exit from any IP in IP tunnel. The document updates
RFC 3168 (the main ECN RFC) and RFC 4301 (IPsec) to say that all
IP in IP tunnels should follow the new rules for setting the ECN bits.
The new rules are similar to the IPsec rules, with the exception of
special handling for several previously unused combinations of the
ECN bits. These unused combinations provide support for PCN
(Pre-Congestion Notification).

The primary security concern here is that the ECN bits can serve as
a covert channel allowing parties inside and outside the secure area
to communicate even though they are not supposed to be able to do so.
Malicious parties inside the secure area can set the ECN bits on
packets to carefully selected values, exposing 2 bits of information
per packet to parties outside the secure area. This covert channel
can also operate in the opposite direction (insecure to secure).

During the development of RFC 4301, the IPsec Working Group evidently
determined that the risks of leaving this small covert channel open are
exceeded by the benefits of allowing ECN information to be properly
processed end-to-end. Therefore, they elected to permit the ECN bits
to be copied from inner to outer IP headers at tunnel ingress
(encapsulation) and described how the ECN bits in the outer IP header

Re: RSVP directorate formed

Lars

This is great news!

James

At 08:01 AM 5/10/2010, Lars Eggert wrote:
>Hi,
>
>following the discussion during the IETF-77 TSVAREA meeting on how 
>to better review and progress extensions to (non-TE) RSVP and 
>IntServ, the transport area directors have formed a new RSVP 
>directorate and given it these tasks:
>
>   * Review of all new work related to RSVP and Integrated Services that
>     is proposed for IETF adoption. The purpose of this review is to
>     advise the ADs and the chairs of the Transport Area Working Group
>     (TSVWG) on whether a particular proposal should be taken on as a
>     work item. The directorate will continue to guide and review such
>     new work in TSVWG until it is ready for publication as an RFC.
>
>   * Review of selected documents during IETF last call or under IESG
>     review. The directorate monitors ongoing IETF work and should
>     independently decide when a document will benefit from their review,
>     assign a reviewer and enter into a follow-on discussion with the
>     authors. When deemed necessary, the area directors will on occasion
>     directly consult the directorate while forming their opinion on
>     selected documents being under review by the IESG.
>
>   * Cross-working group review. RSVP documents may have relevance to

TSVWG status for 14th May 2010

The email below gives a brief snapshot of the current WG status for May.

There are a few individual drafts that have been around for a while, and 
it would be good to receive comments on this list.

We look forward to discussions on the list,

Gorry & James
(TSVWG Chairs)

==================================================================

Published

   RFC 5865 draft-ietf-tsvwg-admitted-realtime-dscp-07 	

IDs in RFC Editor Queue

   draft-ietf-tsvwg-emergency-rsvp
     Norm. ref to router alert draft (in the INT-area WG)

   draft-ietf-tsvwg-rsvp-proxy-approaches

   draft-ietf-tsvwg-rsvp-proxy-proto

IDs in IESG processing

    draft-ietf-tsvwg-port-randomization (DISCUSS)
     	ID revision -07 issued.

RE: [dccp] UDP encaps for SCTP and SCCP

Hi Andrew,

> It would be even better if you could implement DCCP with UDP encap
with
> the baseline UDP networking facilities of Java.  A whole bunch of
> Android developers would grab that.

Oh, that's interesting.  Maybe if I can find some time I'll look at
porting dccp-tp to Android.

Tom P.

> -----Original Message-----
> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On Behalf
Of
> Andrew Lentvorski
> Sent: Tuesday, May 18, 2010 4:19 AM
> To: Lars Eggert
> Cc: DCCP working group; TSV Area; tsvwg <at> ietf.org
> Subject: Re: [dccp] UDP encaps for SCTP and SCCP
> 
> On 5/18/10 12:37 AM, Lars Eggert wrote:
> > Hi,
> >
> > the discussion has touched on lots of things related to UDP encaps,
but
> I haven't seen anything I'd call consensus on the question below. I'd
> therefore like to ask folks to specifically state which option they
> support:
> >

SCTP multihoming: initiate connection to non-primary IP address

Re: SCTP multihoming: initiate connection to non-primary IP address

Kiss, Zoltan (NSN - HU/Budapest) wrote:
> Hi,
> 
> I have a question about a probable error situation of SCTP multihoming.
> In my example, we have two peer, both have 2 IP address. Peer A initiate
> the connection from its primary address Ax to Peer B's primary IP Bx.
> But Bx is unreachable, and for resiliency purposes it would be better if
> the A tries to connect to By (B's secondary address). But the question
> comes, how could A get knowledge of B's secondary address, if the INIT
> ACK doesn't comes? Is there any best practice to this problem? I have
> some ideas, but they are mostly just hacks.
> 

The answer is sctp_connectx() call.  The existence of By would have to
be known at the same time as Bx.  Peer A would pass both Bx and By as
part of the sctp_connectx() or sctp_sendx() and both addresses can then
be tried.

-vlad

> Regards,
> 
> Zoltán, Kiss
> 

Re: SCTP multihoming: initiate connection to non-primary IP address

Hi, Zoltán

For this situation, I think you should enable DAR on both peers before 
initialize SCTP association . Then peer B can update its secondary address to 
peer A using ASCONF .

Regards

Zhou Kaibo 

On Tuesday 18 May 2010 17:07:57 Kiss, Zoltan (NSN - HU/Budapest) wrote:
> Hi,
> 
> I have a question about a probable error situation of SCTP multihoming. In
> my example, we have two peer, both have 2 IP address. Peer A initiate the
> connection from its primary address Ax to Peer B's primary IP Bx. But Bx
> is unreachable, and for resiliency purposes it would be better if the A
> tries to connect to By (B's secondary address). But the question comes,
> how could A get knowledge of B's secondary address, if the INIT ACK
> doesn't comes? Is there any best practice to this problem? I have some
> ideas, but they are mostly just hacks.
> 
> Regards,
> 
> Zoltán, Kiss

RE: UDP encaps for SCTP and SCCP

Tom,

At 15:08 18/05/2010, Phelan, Tom wrote:
>Hi Lars,
>
>Well, I like option 1.
>
>I feel that option 2 is a chimera.  The 'G' in the GUT proposal stands
>for "generic", but it is not entirely generic.  The decapsulation stage
>is specific to the encapsulated protocol.  The GUT draft gives one decap
>rule that is more-or-less suitable for TCP and DCCP.  It doesn't work
>for SCTP.
>
>You have to look in detail at the encapsulated protocols to see if a
>proposed decap works.  With my non-detail understanding of TCP, it looks
>like it works, but we'll need someone to look at that in detail.

The G in GUT is certainly not true for host implementations, but 
importantly the wire protocol is generic for all e2e protocols it 
encapsulates, which is what is important for middleboxes.

>For DCCP, the proposed decap makes partial checksums ineffective.  I
>think it's OK to do that, but you need to state that explicitly in the
>draft, and probably offer guidance on how to deal with partial checksum
>feature negotiation.  You also need to deal with how to signal the use
>of UDP encap, and the other things included in my draft.  Once you've
>done that, you have my draft.
>
>GUT has similar issues for SCTP.  SCTP uses a CRC checksum that doesn't
>include the IP addresses, so the proposed GUT decap doesn't work for it.
>What's needed is actually easier to do.  I don't know enough about SCTP
>to know what else needs to be done.

Earlier on the tsvwg list I was proposing how to get GUT to do a 
partial checksum that only covers its own headers, stopping at the 
encapsulated headers.

>As I've stated before, if you really think through a generic approach,
>it becomes an overall scheme that can be used by all protocols, plus a
>set of protocol-specific adaptations.  That's where we're at with the
>DCCP- and SCTP-specific drafts.
>
>Tom P.
>
> > -----Original Message-----
> > From: tsv-area-bounces <at> ietf.org [mailto:tsv-area-bounces <at> ietf.org] On
> > Behalf Of Lars Eggert
> > Sent: Tuesday, May 18, 2010 3:38 AM
> > To: tsvwg <at> ietf.org
> > Cc: DCCP working group; TSV Area
> > Subject: Re: UDP encaps for SCTP and SCCP
> >
> > Hi,
> >
> > the discussion has touched on lots of things related to UDP encaps,
>but I
> > haven't seen anything I'd call consensus on the question below. I'd
> > therefore like to ask folks to specifically state which option they
> > support:
> >
> > (1) do one SCTP-specific and one DCCP-specific UDP encaps
> > (2) do one generic UDP encaps that can be used with both
> > (3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)
> >
> > Thanks,
> > Lars
> >
> > On 2010-4-22, at 12:57, Eggert Lars (Nokia-NRC/Espoo) wrote:
> > > Hi,
> > >
> > > as most of you probably know, there are two different proposals for
>how
> > to encapsulate SCTP and DCCP inside UDP.
> > >
> > > One approach proposes two protocol-specific encapsulation schemes
> > (described in draft-tuexen-sctp-udp-encaps and
>draft-ietf-dccp-udpencap).
> > >
> > > The second approach proposes a generic encapsulation scheme that can
>be
> > applied to both SCTP and DCCP (draft-manner-tsvwg-gut).
> > >
> > > As a community, we do need to come to consensus on which of these
>two
> > approaches we want to follow when it comes to UDP encapsulation of
>SCTP
> > and DCCP. I believe it would be very confusing if we were to
>standardize
> > both approaches.
> > >
> > > I'd hence like to ask folks to read the three documents and post
>their
> > views to the tsvwg <at> ietf.org list. I'm personally especially interested
>in
> > hearing from folks who aren't on the author lists of the documents,
>but
> > obviously, the authors expert opinions do matter.
> > >
> > > Thanks,
> > > Lars
> > >
> > > PS: I'm pushing on this topic, because UDP encapsulation is the last
> > remaining work item in the DCCP working group before it can close...

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design