Subject: [BEHAVE] Closing the mailing list

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Jan 2020 12:15:03 +0000

Hi,

I am now closing the behave mailing list. Based on the lack of traffic on
this list the last years it is clear that it can be safely closed down. 

I want to thank you all that contributed to the Behave WG.

Cheers

Magnus Westerlund

TSV AD

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Jan 2020 13:38:41 +0100

Thanks for sending the email, Magnus.

IMHO:

Too bad. Of course, folks who did not partake in BEHAVE would have no
idea that BEHAVE would be the right mailing list to ask about NAT/ALG/FW
transit questions, so the name is certainly not helpful to encourage
communications, but i can as of yet not see that the underlying issues
that led to BEHAVE have vanished from the Internet and even more so
private networks, and any other WG we have might be even less of a
welcoming community to discuss NAT issues sould they arise (just
imaginging how welcoming 6man is to any poor folks that (think they)
really need IPv6/IPv6 NAT).

Whats the benefit of closing the list ? If someone has calculated that
the 20 KByte of disk space required to maintain it on IETF servers costs
50 cents/quarter, i am happy to shoulder that cost.

Reminds me of fukoshima. There was a nice report that the last really
bad flood was something like 80 years ago, so everbody warning to
continue to be prepared died, and hence fukoshima was built as
badly as it was. Or if that was too far fetched: As long as NAT exists
as a challenge for the Internet, we should have a mailing list like BEHAVE,
absence of communications is just ongoing luck (or bad naming) but no argument for
removing the list (IMHO).

Cheers
    Toerless

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Jan 2020 10:46:35 -0500

> 50 cents/quarter, i am happy to shoulder that cost.

I also don't know why we close lists for WGs that have documents in the wild.
The result is that we can't process errata.  If you get stream of
unsubscribes are a result of this thread, fine, people have sorted themselves.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Dave Thaler <[email-masked]>
Date: Sat, 11 Jan 2020 00:00:50 +0000

The Behave WG was closed 7 years ago and documents moved to other groups like TRAM (WG still open)
and PCP (WG now also closed), or the transport area list.

This list had some discussion up through 2018 or so, but since then has had no substantial discussions.
In the past year there have only been 3 messages, all of which came from the AD and got no responses.

Most messages to the behave list are spam that I have to deal with frequently so others don't.

I don't see that this list has provided any real value in over a year so I have no objection to closing it
and redirecting any future queries to another list (whether TRAM or TSVWG or whatever else).

Dave Thaler
List Moderator and (former) Behave chair

-----Original Message-----
From: Behave <[email-masked]> On Behalf Of Michael Richardson
Sent: Friday, January 10, 2020 7:47 AM
To: Toerless Eckert <[email-masked]>; Magnus Westerlund <magnus.westerlund=[email-masked]>; [email-masked]
Subject: Re: [BEHAVE] Closing the mailing list

I also don't know why we close lists for WGs that have documents in the wild.
The result is that we can't process errata.  If you get stream of unsubscribes are a result of this thread, fine, people have sorted themselves.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C234ad8b79b024142066408d795e44ea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142680646046670&amp;sdata=GFpyb7XoX%2BWJqZrjsSsWRa8SfGSuLxYB4FK1VnRbaOI%3D&amp;reserved=0        |   ruby on rails    [

---

From: Dan Wing <[email-masked]>
Date: Fri, 10 Jan 2020 16:47:33 -0800

BEHAVE's most impactful work, NAT64 and DNS64, have finished and cause little-to-no discussion.  The related important work, 464xlat, was in v6ops because BEHAVE had closed by then.  The issues of ALGs remains but fortunately the strong trend towards encryption prevents ALGs from harming protocol enhancements.  The big take-away from BEHAVE is adding more technical workarounds to patch over inadequate endpoints builds more fragile systems. I have brought that learning into other protocols and into my day job.  TSVWG is a great place to continue any NAT- or BEHAVE-related topics, as necessary.

Thanks to everyone for the opportunity I received to co-chair BEHAVE for several years.

-d

> On Jan 10, 2020, at 4:00 PM, Dave Thaler <dthaler=[email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 11 Jan 2020 05:13:48 -0800

Let use as example RFC 6889, the first RFC is the list at https://tools.ietf.org/wg/behave/.  The RFC editor page for that document (https://www.rfc-editor.org/info/rfc6889) explicitly says:

"Discuss this RFC: Send questions or comments to [email-masked]"

After closing the behave mailing list, will that page be updated to point to [email-masked]? If yes, then I do not see any problem with closing the behave mailing-list.

Thanks.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jan 2020 10:28:04 +0100

> and redirecting any future queries to another list (whether TRAM or TSVWG or whatever else).

So, i am uninitiated, i read some BEHAVE RFC and try to figure out where
to ask a question. I guess i can figure out that the RFC originated from
behave. 

How would i figure out the redirect of "Ask BEHAVE questions on TSVWG
mailing list" ?

Ai am not aware of any actual redirect pointers in datatracker, but
hopefully i am wrong.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Rob Evans <[email-masked]>
Date: Mon, 13 Jan 2020 09:33:46 +0000

Hi,

> Ai am not aware of any actual redirect pointers in datatracker, but

If a WG has closed, then I suppose the redirect could come from asking a 
question on ietf@ietf?

IME, it's not the bits on the server in the bowels of the IETF, mailing 
lists collect entropy quickly -- a list I manage has just had it's first 
posting for probably about a year, and there are 14 bounces that need to 
be culled.

At which point have enough subscribers changed email address that the 
list is no longer useful, and how do you monitor that?

Cheers,
Rob

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jan 2020 11:02:19 +0100

> If a WG has closed, then I suppose the redirect could come from asking a

Sure, if thats the agreed rediret resolution mechansism, it would be
good if that information was stated in a sentence on the WG weg page,
eg.: https://datatracker.ietf.org/wg/behave/about/

But if there is so little email to a closed WG mailing list, why not
add [email-masked] to the mailing list anyhow so that the request gets
forwarded automatically ? Its not as if [email-masked] would have
less spam problems anyhow.

> posting for probably about a year, and there are 14 bounces that need to be
> culled.

Yes, culling of dead addresses is an astoundly rarely automated part of
mailing list maintenance.

Just change the mailing list to return errors to sender instead of
mailing list administrator when it changes into maintenance mode
(WG closed + N years).

> At which point have enough subscribers changed email address that the list
> is no longer useful, and how do you monitor that?

Yes. Technically the best idea to me would be to remove membership
from the mailing list, redirect it to [email-masked], but as part of
redirect make sure that the subject is prepended with a well-known
prefix like "[WGNAME]: ", so that folk interested in that (historic)
topic would be able to easily filter for it and not have to continuosly
track all of [email-masked]. Instead of [email-masked] one could of course
also set up a separate list like [email-masked].

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jan 2020 13:07:36 +0000

Hi Marc,

The below aspect I am investigating. I would actually assume that this is
normally not updated, but is possibly something that should be improved on so
that pages are kept relevant. 

Cheers

Magnus

On Sat, 2020-01-11 at 05:13 -0800, Marc Petit-Huguenin wrote:
> Let use as example RFC 6889, the first RFC is the list at 
> https://tools.ietf.org/wg/behave/.  The RFC editor page for that document (
> https://protect2.fireeye.com/v1/url?k=26a4afbd-7a70a403-26a4ef26-86742d02e7e2-97c33c5e644c26cc&q=1&e=e7ea07fc-a821-4aa6-a7e0-104daca937f9&u=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc6889
> ) explicitly says:
> 
> After closing the behave mailing list, will that page be updated to point to 
> [email-masked]? If yes, then I do not see any problem with closing the behave
> mailing-list.
> 
> Thanks.
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jan 2020 13:14:38 +0000

> unsubscribes are a result of this thread, fine, people have sorted themselves.

I think the largest cost is in volunteer effort from having someone moderate the
list. If someone is willing to become admin of the list then I can keep it alive
for now as there apparently some that care. 

When it comes to errata there are some benefit in the mailing list. There are
actually 7 Errata that are not processed. 

RFC5766 (4933) 	17.3.3 	Technical 	behave (tsv) 	shakeeb 	TEXT 	
2017-02-15
RFC5769 (4776) 	2 	Technical 	behave (tsv) 	software should include
manufacturer and version number 	TEXT 	2016-08-12
RFC6052 (5415) 	2.2 	Technical 	behave (tsv) 	Dale R. Worley 	TEXT 	
2018-07-01
RFC6062 (3467) 	5.2. 	Technical 	behave (tsv) 	Nazmus Shakeeb 	TEXT 	
2013-01-22
RFC6145 (4090) 	6 	Technical 	behave (tsv) 	Fernando Gont 	TEXT 	
2014-08-20
RFC6146 (4756) 	3.5.3 	Technical 	behave (tsv) 	Alberto Leiva Popper 	
TEXT 	2016-08-02
RFC7050 (5152) 	IANA Conside 	Technical 	behave (tsv) 	Mark Andrews 	
TEXT 	2017-10-11

If I get recommendation for how to handle them I will sanity check the
recommendation and then register it in the system. 

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Jan 2020 09:35:29 +0000

Hi,

As I received an volunteer to admin the mailing list I will leave it open.
Thanks Michael Richardson. 

Cheers

Magnus Westerlund

On Fri, 2020-01-10 at 12:15 +0000, Magnus Westerlund wrote:
> Hi,
>  
> I am now closing the behave mailing list. Based on the lack of traffic on this
> list the last years it is clear that it can be safely closed down.
>  
-- 
Cheers

Magnus Westerlund

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Jan 2020 18:02:49 -0500

> actually 7 Errata that are not processed.

exactly.

    > recommendation and then register it in the system.

okay, I guess we need to read them and post some suggestions.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Jan 2020 18:11:14 -0500

https://www.rfc-editor.org/errata_search.php?eid=4933

    4933> Section 17.3.3 says:

    4933> An attacker might attempt to disrupt service to other users of the
    4933> TURN server by sending Refresh requests or CreatePermission requests
    4933> that (through source address spoofing) appear to be coming from
    4933> another user of the TURN server.  TURN prevents this by requiring
    4933> that the credentials used in CreatePermission, Refresh, and
    4933> ChannelBind messages match those used to create the initial
    4933> allocation.  Thus, the fake requests from the attacker will be
    4933> rejected.
    4933> Notes:

    4933> When using short-term, credentials expire after a specific amount of time
    4933> (such as 5
    4933> minutes) and clients get new credentials. The restriction imposed at section
    4933> 17.3.3
    4933> prevents from refreshing allocation or permission using the new credentials.

    4933> This RFC approves RFC 5389. So one can use short-term credentials. But
    4933> short-term credentials are useless if it can not be used to refresh
    4933> allocation or permission.

    4933> The goal of 17.3.3 can be achieved by sending 438 with the new nonce.

a) I think we should accept this as verified.
b) It seems that sending with the new nonce will work.  This requires some
   text changes, and we can now perhaps use the errata patcher with XML.
   I've asked for the XML (if there is any), and I'll suggest some changes to
   the text.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 16 Jan 2020 19:25:32 -0500

as there is a turn-related working group (tram) alive, I suggest you 
also post to the tram ml.

Marc.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Jan 2020 20:26:52 -0500

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 11:37:39 -0500

> RFC5766 (4933) 	17.3.3 	Technical 	behave (tsv) 	shakeeb 	TEXT 2017-02-15
    > RFC5769 (4776) 	2 	Technical 	behave (tsv) 	software should include manufacturer and version number 	TEXT 	2016-08-12
    > RFC6052 (5415) 	2.2 	Technical 	behave (tsv) 	Dale R. Worley 	TEXT 2018-07-01
    > RFC6062 (3467) 	5.2. 	Technical 	behave (tsv) 	Nazmus Shakeeb 	TEXT 2013-01-22
    > RFC6145 (4090) 	6 	Technical 	behave (tsv) 	Fernando Gont 	TEXT 2014-08-20
    > RFC6146 (4756) 	3.5.3 	Technical 	behave (tsv) 	Alberto Leiva Popper TEXT 	2016-08-02
    > RFC7050 (5152) 	IANA Conside 	Technical 	behave (tsv) 	Mark Andrews TEXT 	2017-10-11

    > recommendation and then register it in the system.

Wow, that's a few.
I'll started on the first.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jan 2020 10:00:48 -0800

Both a/b seem sensible to me.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Jan 2020 16:28:55 +0000

Hi,

I think the primary question is if this errata points to an issue that remains
within the updated TURN specification: 

https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

So the question to the TRAM WG people. 

Section 21.3.3. (the equivalent to 17.3.3) has the same text. However, I think
the underlying question is if the existing mechanism and especially for stale
nonce prevents an insider attacker that otherwise have the user name and
password for the user can take over an allocation when the nonce expires? 

However, I have the suspistion that the reporter has made an erronous assumption
as short-term security is not allowed with TURN. Section 4 of RFC 5766 do
requires long-term or other equal strong mechanism. Thus, another aspect is if
the nonce actually will expire? Or can a client actually loose their allocations
when the nonce expires and attacker manages to make the request first? 

Cheers

Magnus Westerlund

-- 
Cheers

Magnus Westerlund

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 27 Jan 2020 12:56:23 +0000

The short-term credential mechanism for TURN is discussed in https://tools.ietf.org/html/rfc7635, it addresses both the issues raised by the reporter

a) Section 9 says,  If the access token expires, then the client MUST obtain a new token from the authorization server and use it for new
    allocations.  The client MUST use the new token to refresh existing allocations.  This way, the client has to maintain only
    one token per TURN server.
b) Section 11 discusses frequently changing the nonce.

Cheers,
-Tiru

> From: tram <[email-masked]> On Behalf Of Magnus Westerlund
> Sent: Friday, January 24, 2020 9:59 PM
> To: [email-masked]; juberti=[email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tram] [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh
> requests when using short-term credentials
> 
> Hi,
> 
> However, I have the suspistion that the reporter has made an erronous
> assumption as short-term security is not allowed with TURN. Section 4 of RFC
> 5766 do requires long-term or other equal strong mechanism. Thus, another
> aspect is if the nonce actually will expire? Or can a client actually loose their
> allocations when the nonce expires and attacker manages to make the
> request first?
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> > >     4933> This RFC approves RFC 5389. So one can use short-term
> credentials.
> > > But
> > >    text changes, and we can now perhaps use the errata patcher with
> XML..