Linfeng Zheng | 2 Mar 04:29 2012
Picon

Any update on next interim?

Dear all,
 

Thanks Dave for the 02/16 minute. Any plan for our WG meeting? Paris?

--
谢谢,郑林峰 John Linfeng Zheng 
 
天地彩华文化信息咨询有限责任公司 CHA Consulting Firm
执行董事/经理 President/CEO
 
电话(Tel): +86-591-83809031(O)  15306915548(Cell) 15195762065(宁NJ)
地址(Addr): 福州市福新路239号双子星大厦三楼B区810,P.R.China

<div>
<div>Dear all,</div>
<div>&nbsp;</div>
<div>
<br clear="all">Thanks Dave for the 02/16 minute. Any plan for our WG meeting? Paris?</div>
<div>
<br>-- <br>
</div>
<div>
<span><span>&#35874;&#35874;&#65292;&#37073;&#26519;&#23792;</span></span> John Linfeng Zheng&nbsp;</div>

<div>&nbsp;</div>
<div>&#22825;&#22320;&#24425;&#21326;&#25991;&#21270;&#20449;&#24687;&#21672;&#35810;&#26377;&#38480;&#36131;&#20219;&#20844;&#21496; CHA Consulting Firm</div>
<div>&#25191;&#34892;&#33891;&#20107;/&#32463;&#29702; President/CEO</div>
<div>&nbsp;</div>
<div>&#30005;&#35805;(Tel): +86-591-83809031(O)&nbsp; 15306915548(Cell) 15195762065(&#23425;NJ) </div>
<div>&#22320;&#22336;(Addr): &#31119;&#24030;&#24066;&#31119;&#26032;&#36335;239&#21495;&#21452;&#23376;&#26143;&#22823;&#21414;&#19977;&#27004;&#65314;&#21306;810&#65292;P.R.China</div>
<div><span><span>&#21338;&#23458;(Blog):<span>&nbsp;</span><a href="http://blog.sina.com.cn/23gtrees" target="_blank">http://blog.sina.com.cn/23gtrees</a></span></span></div>

<br>
</div>
internet-drafts | 2 Mar 09:59 2012
Picon

I-D Action: draft-ietf-behave-64-analysis-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Analysis of Stateful 64 Translation
	Author(s)       : Reinaldo Penno
                          Tarun Saxena
                          Mohamed Boucadair
                          Senthil Sivakumar
	Filename        : draft-ietf-behave-64-analysis-07.txt
	Pages           : 15
	Date            : 2012-03-02

   Due to specific problems, NAT-PT was deprecated by the IETF as a
   mechanism to perform IPv6-IPv4 translation.  Since then, new efforts
   have been undertaken within IETF to standardize alternative
   mechanisms to perform IPv6-IPv4 translation.  This document analyzes
   to what extent the new stateful translation mechanisms avoid the
   problems that caused the IETF to deprecate NAT-PT.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-07.txt

Etienne Dublé | 2 Mar 18:10 2012
Picon
Picon

Re: RFC 6535 on Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)

Le 29/02/2012 19:58, rfc-editor <at> rfc-editor.org a écrit :
> A new Request for Comments is now available in online RFC libraries.
>
>
>          RFC 6535
>
>          Title:      Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
>

Hello,
And thanks for this very interesting document.
I just noticed the following: it seems the RFC numbers are swapped in 
the following sentence (part 7.)

"
This document recommends the socket API-layer implementation
option over network layer translation, i.e., it recommends the
approach introduced in RFC 2767 over the approach of RFC 3338.
"

I would also like to point you to the following tool: 
http://sourceforge.net/projects/ipv6-care/. It uses an approach very 
similar to the RFC, with some additional features (and also things that 
should be improved with respect to the RFC). For example it can also 
handle servers.
At https://twiki.cern.ch/twiki/bin/view/EGEE/IPv6CARE you can view a 
video where mysql client and server are talking over IPv6, although none 
of them are IPv6-compliant.
I am the main developper of this tool. IPv6 CARE stands for IPv6 
Compliant Automatic Runtime Environment, it's free and open source 
(Apache license). It uses the API translation mechanism (LD_PRELOAD on 
UNIX).

FYI, I listed below the differences I noticed between the behavior of 
IPv6 CARE and the behavior described in the RFC.
If you have comments about it I would be happy to read them.
Regards
Etienne Duble

--------------

Differences IPv6 CARE / RFC:
- IPv6 CARE also addresses the case of servers (TCP, for now) i.e. when 
patching a server it ensures (at accept() time) that both IPv4 and IPv6 
clients can connect: when needed it opens an additional IPv6 socket and 
performs a select().
- For clients, the mechanism in IPv6 CARE is sometimes triggered at 
connection time, not only at name resolution time. For example if the 
client tries to connect to a dual-stack server (A and AAAA records 
available), the A record will be tried first, and if the connect() call 
fails, then the tool will also try to connect using the IPv6 address of 
the server. Since this is triggered by the connection failure, all this 
is implemented during the connect() phase.
- IPv6 CARE is more complicated. For example in the previous case the 
connect() call is replaced by a specialized algorithm, and therefore the 
trivial 'function mapper' described in the RFC cannot be applied.
- IPv6 CARE also addresses the conversion of addresses (i.e. when a 
synthetic IPv4 address is involved), from binary to text and from text 
to binary (modification of inet_ntoa, inet_aton, inet_ntop, ...)
- The 'Special Exclusion Sets' are not implemented (yet). For now the 
pool is configured at installation time with a subnet of RFC1918 addresses.
- IPv6 CARE does not handle ICMP (i.e. it keep it untouched).
- Security aspects in IPv6 CARE should be improved.

--

-- 
Etienne Dublé
CNRS / LIG - Drakkar and Hadas teams
+33 (0)476827276

Dan Wing | 2 Mar 19:49 2012
Picon

Re: Any update on next interim?

> -----Original Message-----
> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
> Behalf Of Linfeng Zheng
> Sent: Thursday, March 01, 2012 7:29 PM
> To: behave <at> ietf.org
> Cc: behave-chairs <at> tools.ietf.org
> Subject: [BEHAVE] Any update on next interim?
> 
> Dear all,
> 
> 
> Thanks Dave for the 02/16 minute. Any plan for our WG meeting? Paris?

We had an interim meeting today (March 2).  This was announced on the BEHAVE
mailing list and by the IESG Secretary.

We will _not_ have a face-to-face meeting in Paris.  We cancelled that
meeting because the Transport area had too many conflicts and chairs were
encouraged to drop sessions if possible.  Based on our February 16 interim
conference call, the chairs felt we could cancel the face-to-face meeting in
Paris without significantly harming forward progress on the working group's
milestones.

Our next conference call interim meeting is tentatively scheduled for
Thursday, April 19, 7am Pacific Time.  This is three weeks after the IETF in
Paris.  We will be finalizing that date/time and make an official
announcement during the IETF week.  

The guidance for conference call interim meetings is published at
http://www.ietf.org/iesg/statement/interim-meetings.html, and requires a two
week notice prior to conference call interim meetings.

-d

> --
> 
> 谢谢,郑林峰 John Linfeng Zheng
> 
> 天地彩华文化信息咨询有限责任公司 CHA Consulting Firm
> 执行董事/经理 President/CEO
> 
> 电话(Tel): +86-591-83809031(O)  15306915548(Cell) 15195762065(宁NJ)
> 地址(Addr): 福州市福新路239号双子星大厦三楼B区810,P.R.China
> 博客(Blog): http://blog.sina.com.cn/23gtrees

_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave
Picon

FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt

This I-D describes a new STUN usage for enabling WebRTC implementations
to perform consent freshness. It is far from complete, but comments
(especially on the design considerations/approach) are welcome..

Muthu

-----Original Message-----
From: i-d-announce-bounces <at> ietf.org
[mailto:i-d-announce-bounces <at> ietf.org] On Behalf Of
internet-drafts <at> ietf.org
Sent: Monday, March 05, 2012 2:14 AM
To: i-d-announce <at> ietf.org
Subject: I-D Action: draft-muthu-behave-consent-freshness-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : STUN Usage for Consent Freshness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Hadriel Kaplan
	Filename        : draft-muthu-behave-consent-freshness-00.txt
	Pages           : 10
	Date            : 2012-03-04

   This document describes a STUN usage that enables WebRTC
   implementations to verify the peer consent for continuing to receive
   traffic on a candidate pair ICE is using for a media component after
   session establishment.  Verification of peer consent is necessary to
   ensure that a malicious JavaScript cannot use the browser as a
   platform for launching attacks.  This form of consent verification
   also serves the purpose of refreshing NAT bindings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness
-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness-
00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Simon Perreault | 5 Mar 16:02 2012
Picon

Re: FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt

On 2012-03-04 16:27, Muthu Arul Mozhi Perumal (mperumal) wrote:
> This I-D describes a new STUN usage for enabling WebRTC implementations
> to perform consent freshness. It is far from complete, but comments
> (especially on the design considerations/approach) are welcome..

I had a *very* quick look at it, and have a few questions. They're 
mostly "explain it to me like a two year old" type questions, so maybe 
the answers could be added to the doc itself.

- Looking at section "6. STUN Consent Method Processing", I don't see 
any difference between a Binding request and a Consent request on the 
server side. So how could a Consent request have different semantics 
than a Binding request if they are processed identically by the server?

- Why a new method instead of a new attribute? A new attribute 
indicating additional semantics seems more appropriate to me because all 
Binding processing would automatically be inherited by Consent. E.g. in 
the future we define a new Binding attribute, chances are it would also 
apply to Consent. All you need is a way to indicate "this is a regular 
Binding request but *additionally* I'm asking if you consent to me 
sending you packets". The server would include the consent attribute in 
the response if it consents, otherwise, and if it doesn't support that 
attribute, it would just ignore it and reply like a normal Binding 
request, which would be useful. Also you would inherit a lot of text 
about the mechanics (e.g. sections 6.1-6.4 marked TBD would be unnecessary).

Simon
--

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
The IESG | 6 Mar 18:10 2012
Picon

Document Action: 'Analysis of Stateful 64 Translation' to Informational RFC (draft-ietf-behave-64-analysis-07.txt)

The IESG has approved the following document:
- 'Analysis of Stateful 64 Translation'
  (draft-ietf-behave-64-analysis-07.txt) as an Informational RFC

This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.

The IESG contact persons are David Harrington and Wesley Eddy.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-behave-64-analysis/

Technical Summary

Due to specific problems, NAT-PT was deprecated by the IETF as a
mechanism to perform IPv6-IPv4 translation. Since then, new efforts
have been undertaken within IETF to standardize alternative
mechanisms to perform IPv6-IPv4 translation. This document evaluates
how the new stateful translation mechanisms avoid the problems that
caused the IETF to deprecate NAT-PT.

Working Group Summary

Nothing exciting happened.

Document Quality

This is not a protocol,  but an analysis document.
Therefore there are no implementations or promises to implement.

Personnel

shepherd: Dan Wing
responsible AD: David Harrington

RFC Editor Note

  please move pcp-base to the normative reference section.
Picon

Re: FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt

|- Looking at section "6. STUN Consent Method Processing",
|I don't see any difference between a Binding request and 
|a Consent request on the server side. So how could a Consent 
|request have different semantics than a Binding request if 
|they are processed identically by the server?

To make sure I understand correctly, by a server you don't mean a STUN
server sitting in the Internet used for resolving the NAT'ed address,
right? Such a server isn't expected to receive a consent request.
Consent request/response is expected to be used b/w two endpoints
involved in a real-time communication session.

From the server side, the main difference b/w the Binding request
processing and the Consent request processing is the message integrity
verification. While a Binding request in the ICE usage would require
verification of the message integrity using the short-term credential
mechanism, the consent request will not. A consent request is also not
expected to contain any other attribute except FINGERPRINT (and probably
SOFTWARE). So, once the server identifies it as a consent request based
on the message type fields in the STUN header, it would branch out of
Binding request processing and process the request as a consent request.

I agree this isn't clearly described in section 6 and it needs to be
updated.

|- Why a new method instead of a new attribute?

As described in the design considerations section, the ICE usage
requires the message integrity and short-term credentials to be used
with Binding request/response. These are not needed for consent
freshness. One could add a new attribute to call out an ICE exception.
However, depending on where in the stack an implementation does the
integrity verification, an implementation may throw out a Binding
request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
attributes. In addition, a Binding request sent for consent freshness
can cause ICE reprocessing if an implementation doesn't handle it
properly.

I am not saying it can't be done using a new attribute. But, using a new
method looks cleaner and less troublesome with existing deployments.

Muthu

|-----Original Message-----
|From: Simon Perreault [mailto:simon.perreault <at> viagenie.ca]
|Sent: Monday, March 05, 2012 8:33 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: behave <at> ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action:
draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-04 16:27, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> This I-D describes a new STUN usage for enabling WebRTC
implementations
|> to perform consent freshness. It is far from complete, but comments
|> (especially on the design considerations/approach) are welcome..
|
|I had a *very* quick look at it, and have a few questions. They're
|mostly "explain it to me like a two year old" type questions, so maybe
|the answers could be added to the doc itself.
|
|- Looking at section "6. STUN Consent Method Processing", I don't see
|any difference between a Binding request and a Consent request on the
|server side. So how could a Consent request have different semantics
|than a Binding request if they are processed identically by the server?
|
|- Why a new method instead of a new attribute? A new attribute
|indicating additional semantics seems more appropriate to me because
all
|Binding processing would automatically be inherited by Consent. E.g. in
|the future we define a new Binding attribute, chances are it would also
|apply to Consent. All you need is a way to indicate "this is a regular
|Binding request but *additionally* I'm asking if you consent to me
|sending you packets". The server would include the consent attribute in
|the response if it consents, otherwise, and if it doesn't support that
|attribute, it would just ignore it and reply like a normal Binding
|request, which would be useful. Also you would inherit a lot of text
|about the mechanics (e.g. sections 6.1-6.4 marked TBD would be
unnecessary).
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
Simon Perreault | 6 Mar 19:49 2012
Picon

Re: FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt

On 2012-03-06 13:06, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |- Looking at section "6. STUN Consent Method Processing",
> |I don't see any difference between a Binding request and
> |a Consent request on the server side. So how could a Consent
> |request have different semantics than a Binding request if
> |they are processed identically by the server?
>
> To make sure I understand correctly, by a server you don't mean a STUN
> server sitting in the Internet used for resolving the NAT'ed address,
> right? Such a server isn't expected to receive a consent request.
> Consent request/response is expected to be used b/w two endpoints
> involved in a real-time communication session.

Right. By "server" I mean the peer that receives the STUN request.

> From the server side, the main difference b/w the Binding request
> processing and the Consent request processing is the message integrity
> verification. While a Binding request in the ICE usage would require
> verification of the message integrity using the short-term credential
> mechanism, the consent request will not. A consent request is also not
> expected to contain any other attribute except FINGERPRINT (and probably
> SOFTWARE). So, once the server identifies it as a consent request based
> on the message type fields in the STUN header, it would branch out of
> Binding request processing and process the request as a consent request.

What does "process the request as a consent request" mean? From the 
draft it looks like it could mean exactly the same as for a Binding 
request...

In other words, what's the difference between a consent request and a 
keepalive?

> |- Why a new method instead of a new attribute?
>
> As described in the design considerations section, the ICE usage
> requires the message integrity and short-term credentials to be used
> with Binding request/response. These are not needed for consent
> freshness. One could add a new attribute to call out an ICE exception.

I'm not following you. ICE requires short-term auth for *connectivity 
checks*. Those are done *before* ICE concludes. ICE does not require 
short-term auth for Binding requests sent *after* ICE concludes. For 
keepalives, it even says that auth must not be used.

> However, depending on where in the stack an implementation does the
> integrity verification, an implementation may throw out a Binding
> request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
> attributes. In addition, a Binding request sent for consent freshness
> can cause ICE reprocessing if an implementation doesn't handle it
> properly.

That argument can be used to justify anything. I could say that your new 
Consent request could be interpreted as a Crash-Right-Now message if an 
implementation doesn't handle it properly.

Simon
--

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
Picon

Re: FW: I-D Action:draft-muthu-behave-consent-freshness-00.txt

|In other words, what's the difference between a consent request
|and a keepalive?

A keepalive is a Binding indication that does not evoke a response,
whereas a consent request does.

|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.

<snip from the RFC5245>
   B.4.  Importance of the STUN Username

   ICE requires the usage of message integrity with STUN using its
   short-term credential functionality.  The actual short-term
   credential is formed by exchanging username fragments in the SDP
   offer/answer exchange.

   B.10.  Why Are Binding Indications Used for Keepalives?

   Additionally, using a Binding Indication allows integrity to be
   disabled, allowing for better performance.  This is useful for large-
   scale endpoints, such as PSTN gateways and SBCs.
</snip>

It doesn't look ICE intended to limit the message integrity and
short-term auth for connectivity checks alone -- it looks applicable for
any Binding request/response transaction.

<snip from the RFC5245>
   10.  Keepalives
   Though Binding Indications are used for keepalives,
   an agent MUST be prepared to receive a connectivity check as well.
   If a connectivity check is received, a response is generated as
   discussed in [RFC5389], but there is no impact on ICE processing
   otherwise.
</snip>

If a connectivity check is received for keepalive, it should use the
message integrity and short-term auth, I think.

Muthu

|-----Original Message-----
|From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
Behalf Of Simon Perreault
|Sent: Wednesday, March 07, 2012 12:20 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: behave <at> ietf.org
|Subject: Re: [BEHAVE] FW: I-D
Action:draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-06 13:06, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |- Looking at section "6. STUN Consent Method Processing",
|> |I don't see any difference between a Binding request and
|> |a Consent request on the server side. So how could a Consent
|> |request have different semantics than a Binding request if
|> |they are processed identically by the server?
|>
|> To make sure I understand correctly, by a server you don't mean a
STUN
|> server sitting in the Internet used for resolving the NAT'ed address,
|> right? Such a server isn't expected to receive a consent request.
|> Consent request/response is expected to be used b/w two endpoints
|> involved in a real-time communication session.
|
|Right. By "server" I mean the peer that receives the STUN request.
|
|> From the server side, the main difference b/w the Binding request
|> processing and the Consent request processing is the message
integrity
|> verification. While a Binding request in the ICE usage would require
|> verification of the message integrity using the short-term credential
|> mechanism, the consent request will not. A consent request is also
not
|> expected to contain any other attribute except FINGERPRINT (and
probably
|> SOFTWARE). So, once the server identifies it as a consent request
based
|> on the message type fields in the STUN header, it would branch out of
|> Binding request processing and process the request as a consent
request.
|
|What does "process the request as a consent request" mean? From the
|draft it looks like it could mean exactly the same as for a Binding
|request...
|
|In other words, what's the difference between a consent request and a
|keepalive?
|
|> |- Why a new method instead of a new attribute?
|>
|> As described in the design considerations section, the ICE usage
|> requires the message integrity and short-term credentials to be used
|> with Binding request/response. These are not needed for consent
|> freshness. One could add a new attribute to call out an ICE
exception.
|
|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.
|
|> However, depending on where in the stack an implementation does the
|> integrity verification, an implementation may throw out a Binding
|> request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
|> attributes. In addition, a Binding request sent for consent freshness
|> can cause ICE reprocessing if an implementation doesn't handle it
|> properly.
|
|That argument can be used to justify anything. I could say that your
new
|Consent request could be interpreted as a Crash-Right-Now message if an
|implementation doesn't handle it properly.
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
|_______________________________________________
|Behave mailing list
|Behave <at> ietf.org
|https://www.ietf.org/mailman/listinfo/behave

Gmane