Re: BCPs and STDs

[Frank Ellermann]

Edward Lewis wrote:
 
> wouldn't it be more professional if it were easier to
> navigate to IETF document from the IETF web pages?

It's one of these "if you know how it's easy" things,

The main page has a search form, upper left corner, the
first thing you see on www.ietf.org, enter "BCP 58",
click "go", and from the familiar Google results pick
the second hit RfC 3233, ready.

*Or* go to the bottom of the the IETF home page, use the
"RfC editor" link, then use "RfC search", enter "58" in
the search form, check the radio buttons for BCP and
"entire word", click search, use the shown link, ready.

> What can't:  http://www.ietf.org/documents/bcp/bcp102.txt
> be all that is needed, with links to Documents and then
> BCP be plainly visible on the web site

Fifth Google hit: 

  Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Stopping loss of transparency...

[Nicholas Staff]

> 
> On 17-aug-2005, at 15:34, Marc Manthey wrote:
> 
> >> Just to be sure: what were talking about is that when a customer  
> >> gets up in the morning and connects to www.ietf.org they get  
> >> www.advertising-down-your-throat.de instead, right?
> 
> > yes , thats exactly what it  does , they call it  "Portal-Guided  
> > Entrance" on port :80 and 443.
> 
> Does this work on port 443? I would assume the SSL security checks  
> wouldn't accept this.

I believe the FQDN is not encrypted, though the part of the url after the
FQDN is (so one could redirect based on https:// and/or specific FQDN's
(whether http or https).  If you've ever used websense I would assume the
technology is similar.

> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 63 On-line Survey

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


> "IETF" == IETF Chair <[EMAIL PROTECTED]> writes:
IETF> http://geneva.isoc.org/surveys/index.php?sid=4 Even if you did
IETF> not attend IETF 63 in Paris, we would value your responses.
IETF> All responses will be treated anonymously, and a summary will
IETF> be available on-line.
 
A question asks how likely I am to attend meetings in:
  North America
  Asia
  Europe

I find it hard to answer this question.

I am less likely to attend meetings in the US than I am to attend them
in Canada.  If I can get sufficient advance warning as to the *continent*
on which a meeting is, then I would say that I am more likely to attend
a meeting in Asia or Europe than in the US.

Right now, to attend a meeting in Europe next summer (fares to Europe in
the summer are always high, and planning family is most difficult during
the summer) I would need to know by September of this year. 

To attend a meeting outside of north america in 2006, I'd need to know
the Fall 2006 meeting location by October of 2005 to make sure that i'd
have budget.

I.e. given warning, my preference for meeting locations are;

 Canada
 Europe
 South America
 1st-world Pacific Rim: Japan/Australia/etc.
 US
 other-harder-to-get-places

- -- 
] Michael Richardson  Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com   Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/www.xelerance.com/training/   |device driver[
]I'm a dad: http://www.sandelman.ca/lrmr/ [

 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQwOc9YqHRg3pndX9AQHHgQQAu6QYl+uu8BsMbxBXfxsnfq+twwvrkYY7
Uz7PItdOfdkPQe83CMEoOGUUtSd3xefSu8yH7vr/oh1HIUWNKQhhWND2uv2k9br6
JXYSj1mEbiEs4FYS3FedkJKKOyHZWIwQWDzbqpOajeTSS7/hAXCzKR8Ozgpv7h+V
Q07lmsTQJgM=
=i9xx
-END PGP SIGNATURE-

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Dave Crocker]

Michael Thomas wrote:
This thread began as a complaint against a particular requirement 
being imposed on a particular pre-working group effort. 


No it did not. Stop imputing my motives.



Michael,

I readily admit to having no clue as to what your motives are.  I can't 
guess... and I haven't tried.


What I DID do was to characterize the semantics of the original posting that 
you sent, creating this thread:


Michael Thomas wrote:
> Having a "threat analysis" was brought up at the plenary by Steve
> Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are
> being required to produce such a thing as a prerequisite to even
> getting chartered as a working group. The problem that I have (and
> Dave Crocker at the plenary) is that there doesn't seem to be
> any definition of what a "threat analysis" is.

Whatever your intent, the text you sent complains that the DKIM effort was 
given a requirement but was not given guidance, notably that we were not given 
a definition of the term that describes the requirement.


Yet you were present at the lunch where our area director gave us both the 
requirement and the definition.


That some of us understood what he said and some of us did not is certainly 
important, of course.  It probably at least means we need more/better guidance.


But it does not change the fact that we were given explicit guidance and a 
definition to back it up.


--

  d/

 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Michael Thomas]

This thread began as a complaint against a particular requirement being 
imposed on a particular pre-working group effort. 


No it did not. Stop imputing my motives.

Mike

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Dave Crocker]

It seems a bit unlikely all of dozen or so relevant people are 
simultaneously
on vacation, but perhaps that's indeed the case. If so, that's fine, but 


And therein lies much of my confusion.

This thread began as a complaint against a particular requirement being 
imposed on a particular pre-working group effort.  It has mostly continued to 
focus on that.  There are only two ADs for the Area under discussion. As far 
as I know, only one has asserted the requirement for a threats analysis and he 
had done it with respect to a single working-group-to-be. That one AD is on 
vacation.


In my view, that one AD is very much trying to be helpful, even as he erected 
this barrier.


(Given the diversity of goals and views on the mass and now the dkim mailing 
lists, his requirement strikes as both timely and useful, for getting group 
consensus about focus, and I am inclined to believe that we really *do* need 
to establish that before chartering rather than seek it after.)


All other discussion about threat analysis concerns trends, preferences, 
needs, eventual requirements and the like.  Hence, they are abstract.  That 
does not at all make them irrelevant or unproductive to pursue, but it strikes 
me that it *does* mean the impact of the discussion is, at best, somewhere in 
the future.  While that certainly means we need to press the security 
community for clear and pragmatic guidance, I do not see how it justifies 
complaining about the need/requirement.



  I am hard-pressed to believe anyone will argue against the 
utility of a guidance document.


And indeed, nobody is making such an argument. Can we finally put this 
strawman to bed, 


Right.  I was merely trying to establish a base of agreement, not to claim you 
had been claiming otherwise.  (Again, I'm just a tad sensitized to diversity 
of views, given the range of directions the DKIM list discussion is going, so 
I want to be careful not to make implicit assumptions.)




We have relied on the communication of guidance and
criteria through other means.  So I think the real question is whether
reasonable, clear, stable criteria are being communicated?


That's the question in a nutshell. And it is my belief that this is not
happening.


I posted a note citing the guidance details we've been given by our AD.  I 
(we) would have loved more notice of the requirement as well as a written, 
pedagogical cookbook for satisfying it.


As for the timing of getting the requirement (only a few days before the BOF) 
I'll take that sort of "sudden" imposition at the *beginning* of a group 
process, over the more-typical late-stage surprise any day of the week.


Since I'm the one that has had the most interaction with our AD on this 
requirement for DKIM, I can only say that I view the sequence as reasonable, 
although obviously needing more work.  Yes, it's unfortunate that some of us 
who heard him impart the requirement misunderstood it.  But some of us did not.



Since the "threat analysis" requirement is  newly-imposed on the rest of us, one can 
expect a  period of time where the communication is iterative and maybe even 
looks like a negotiation.

I would not characterize it as such. An iterative clarifying process might
serve to crystallize management thinking as to what's needed, but 
ideally it should not result in the sorts of changes implied by a give-and-take

negotiation process.


If I thought that a) our AD and the security community were entirely clear 
about the requirement as it applies to an Internet standards process, and b) 
those of us who will be doing the working group work were automatically able 
to perform whatever clarified requirement they settle on, then I would agree 
that it is a clarification process, rather than a negotiation.  I think, 
however, that things are rather more fluid.  Hence "negotiation".


That said, we probably don't have to agree on the terminology and I'm only 
commenting because you and I seem to have such different perspectives on this 
and my comment might help, u, clarify the difference.




Numerious recent events compell me not to share in your enthusiasm. As John
Klensin has remarked in a separate thread, it now seems that the stock 
response to any suggestion or criticism whatsoever is either some sort of 
strawman or reductio ad absurdum argument.


Somehow, I suspect this is where the real tension lies in this exchange.  And 
I've probably made enough public comments to make clear that this larger, IETF 
management problem is one that you and I (and John and a host of others) agree on.


And it is certainly true that the threat analysis pre-requisite for dkim 
chartering could become an exemplar of this problem.


My point, however, is that my own experience is that... so far... it isn't 
even close.  It feels nothing at all to me like an example of the historical 
(and very serious) problem.




  So the question about the threat analysis requirement is whether an
effort that

Re: Stopping loss of transparency...

[Prakash Jayaraman]

It seems this ISP wants to provide proprietary services tailored to each 
customer for differentiation. I am not going to question what they want 
to do, but they can do so without breaking the features you have 
mentioned. This is one of the main problems considered and resolved by 
the PANA WG (not that this ISP is going to adopt the solution just 
because it is available :)   If they specify the requirements in the 
form of an individual draft, IETF could suggest or develop more elegant 
solutions.


- prakash


Roland Bless wrote:


Hi,

just yesterday a larger german DSL/Internet provider activated
- without a real notice - a feature as "field trial" in my city,
so that HTTP(S) requests of customers are redirected to their own
web portal (apparently using some soft state timeout).
I'm also aware of several other dial-up providers who do that.
This breaks IMHO a lot of applications, e.g., DynDNS
registrations of DSL routers (which would not be necessary
with IPv6 but that is another issue), automated Windows/Linux
updates, anti-virus database updates, RSS and presumably many
more. Though they sell it as a "service to
customers" (luckily you still can turn this feature off
if you know how to do it...), I see it as very dangerous
since automated security updates etc. will fail, i.e. they
even decrease the security of their cutomers! Is there
anything newer than RFC 2775 that one could give as
strong technical advice to abandon that feature and to
not turn it on for all other users?

Regards,
Roland

P.S.: please don't comment that I should just switch
the provider in this case. I like to raise the awareness of
the provider that this feature is _technically_ dangerous,
though it may make a lot of sense for the marketing people...

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: what is a threat analysis?

[Russ Housley]

Ned:

> And what we have heard has, for me at least, confused rather than clarified.

I have been away for the last week, so I hope I can resolve this thread 
without causing any further confusion, anger, or frustration.


>> Do you seriously think you could write a "threat analysis"
>> given the definition in 2828?

RFC 2828 says:

   $ threat analysis
  (I) An analysis of the probability of occurrences and consequences
  of damaging actions to a system.

Perhaps a different term is more appropriate.  However, this was the term 
that was used at the first MASS BoF.


> I certainly could write something that conformed to that (very vague)
> definition. Whether or not it would actually be useful, and whether or not
> it would be what's being asked for here, are different matters entirely.

The request for a threat analysis was made at the first MASS BoF.  Several 
people asked what problem was trying to be solved.  The discussion that 
followed made it clear to me that people were unclear how the signing of 
email messages by the domain was going to help the Internet.


In Paris, on the Saturday before IETF 63, when I met with the BoF Chair, 
and it was clear to me that there was a presentation prepared to answer 
this question.  I felt that this open item from the previous BoF deserved a 
response.  I believe that I was correct, as it was raised at the BoF from 
the audience by Eric Rescorla, who was one of the people that spoke about 
it at the first BoF.


> I actually think that, having read several threat analyses and even 
contributed
> to a couple more, I know what a threat analysis is. The problem as I see 
it is
> that there are several different sorts of threat analsysis that coupld 
be done

> in the MASS/DKIM space, and it isn't clear what one we're being asked to
> provide.
>
> For example, one sort would be to look at how DKIM can be directly attacked:
> Private key theft, replays, taking advantage of weaknesses in the delsp
> canonicalization algorithm and/or line count limits, hash function exploits,
> that sort of thing. This would be a highly technical analsysis of the DKIM
> proposal itself.

I did not ask for this type of analysis.  I think that it would be 
inappropriate to ask for this kind of analysis prior to chartering a 
working group.  Obviously, the working group will make changes to DKIM, and 
any change would impact such an analysis.


> Another, somewhat overlapping, analysis would be of likely responses by
> spammers to widespread use of DKIM. This would include creation of bogus but
> similar domains, exploiting the gaps between the signature identity and 
message
> originator information, and so on. This is more a gaming exercise than 
anything

> else (and the obvious tool to use to describe the result would be an attack
> tree).

I did not ask for this type of analysis.  Although, it would be interesting 
to speculate on the response of the bad actors if DKIM is deployed.  This 
analysis is not required in order for a working group to be chartered.


> And yet another would be to look at threats to email in general and 
attempt to
> figure out where DKIM fits in the overall email threat picture. This 
will have
> more the flavor of a justification for the DKIM approach and a 
specification of

> what DKIM is intended to do.

Part of this is needed.  We need to understand where the DKIM entities 
reside in the email system.  We also need to understand where the bad 
actors reside in the email system.  Of course, they may be in more than one 
place.


> My guess is that the third of these is what's being asked for. But 
that's just
> a guess on my part. And maybe I'm just being dense, but the list of 
questions

> to be answered provided by Russ Housley did NOT help clarify this at all:
>
>  * Who are the bad actors?
>  * Where do they fit into the protocol environment (eg, middle of  net)?
>  * What are we trying to prevent them from doing?

Let me try to expand on these ideas.  These are not the exact words that I 
used when speaking to the BoF Chair, but they are close enough.


1.  Who are the bad actors that DKIM is trying to thwart?  Put another way, 
if DKIM is deployed, what bad actors will have to find a different way to 
perform their bad acts.  Also, what resources do these bad actors have at 
their disposal?


2.  Where are these bad actors in the protocol environment?  Where in the 
email system do they pop up to perform the acts that DKIM is trying to 
prevent.  Again, different bad actors may appear at different places.


3.  What are the bad acts that DKIM is trying to thwart?  The first two 
questions are really background for this question.


Without answers to these questions, I do not believe that it is possible to 
write a useful charter for a working group in this area.


> In any case, I for one am completely unwilling to spend time working on this
> until I know what the goal is.

I hope this message provides the information that you are see

Re: Stopping loss of transparency...

[John C Klensin]

--On Wednesday, 17 August, 2005 18:13 +0200 Roland Bless
<[EMAIL PROTECTED]> wrote:

> Hi Brian,
> 
>> You can ask some pointed questions using RFC 4084 ("exactly
>> which of these descriptions applies to your service, and
>> please show
> 
> Thanks for a pointer to that BCP...
> 
>> me in the contract where you are allowed to change your
>> service without notice").  But I suspect that even free
>> copies of
> 
> Unfortunately they have a passage in their general terms and
> conditions which explictly allows them to place their web
> portal as starting page...however, they announced a new
> feature, but one could not infer from that statement that they
> are really redirecting HTTP requests... (for the interested
> reader who is able to read german:
> http://www.heise.de/newsticker/meldung/62869)

Roland,

It is impossible to close every loophole, or to prohibit every
bad behavior.  Certainly it is impossible to do so without
making a document like RFC 4084 so long and complex that no one
would read it.  However, there is a huge difference between
"place their portal as starting page" and "intercept every HTTP
request and divert it to where they want to".  The ordinary
interpretation of the former would mean doing something like
what the WiFi public hotspot folk do, i.e., to intercept your
_first_ URL in some "session" in order to display their page,
set up accounting information, etc.  But, after that, they
generally leave you alone.  

This is much more intrusive.  From your description and that in
the article, it would seem that they are using the "portal"
story as an excuse to force you into a private service, causing
increased costs in terms of the time it takes you to accomplish
anything, etc.  

FWIW, I think Steve Bellovin's advice is wise -- publicity, loud
public protests, appeals to regulators if there are _any_
pressures that prevent you from changing suppliers, etc. might
be effective and are worth trying.

john




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Roland Bless]

Hi Brian,

> You can ask some pointed questions using RFC 4084 ("exactly which
> of these descriptions applies to your service, and please show

Thanks for a pointer to that BCP...

> me in the contract where you are allowed to change your service
> without notice").  But I suspect that even free copies of

Unfortunately they have a passage in their general terms and conditions
which explictly allows them to place their web portal as starting
page...however, they announced a new feature, but one could not
infer from that statement that they are really redirecting HTTP requests...
(for the interested reader who is able to read german:
http://www.heise.de/newsticker/meldung/62869)

> RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.

Right, however, I have a slight hope that they may care, since
they are testing the feature in a limited scope instead of just
enabling it for all users, and, currently one can still turn it off
(but how for long?)

Regards,
 Roland

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Brian E Carpenter writes:
>Roland,
>
>You can ask some pointed questions using RFC 4084 ("exactly which
>of these descriptions applies to your service, and please show
>me in the contract where you are allowed to change your service
>without notice").  But I suspect that even free copies of
>RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.
>

Publicity might help.  A few years ago, my local cable ISP (Comcast) 
deployed a "transparent" web proxy.  This prompted a lot of outrage, 
including claims that they were violating the wiretap law.  They backed 
down in about a week.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: BCPs and STDs

[Edward Lewis]

I guess I should say that wouldn't it be more professional if it were 
easier to navigate to IETF document from the IETF web pages?


As someone who's been around a while, it's hard to "on a dime" find a 
reference without having to build up my own repository.  As I have 
changed employers over the years I have left behind old repositories 
on the equipment I no longer am permitted to use.


I can imagine it's even harder for newcomers to navigate.

What can't:  http://www.ietf.org/documents/bcp/bcp102.txt be all that 
is needed, with links to Documents and then BCP be plainly visible on 
the web site?


BTW, thanks to the references to 2026.  I had forgotten there was 
more than than just the RFC categories and standards track levels.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: BCPs and STDs

[Frank Ellermann]

Edward Lewis wrote:

> It's a lot easier, when all you might have is a hand held
> device, to be able to click though links to see even just
> the title of a document when someone asks "what do you think
> of BCP 58?"

Roll your own interface to the "RfC search", I've done that
for RfCs, example: 

The resulting link is monstrous, but does what I want:

http://www.rfc-editor.org/cgi-bin/rfcsearch.pl?opt=number&num=5&filefmt=txt&search_doc=search_rfc&abstract=abson&keywords=keyon&format=ftp&searchwords=20

For BCP 20 replace "search_rfc" by "search_bcp", similar for
FYI 20 or STD 20.  I test it only for BCP:

http://www.rfc-editor.org/cgi-bin/rfcsearch.pl?opt=number&num=5&filefmt=txt&search_doc=search_bcp&abstract=abson&keywords=keyon&format=ftp&searchwords=20

Works.  For your other questions test it with BCP 9 / RFC 2026.

   Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: BCPs and STDs

[Joe Abley]

On 17-Aug-2005, at 10:48, Edward Lewis wrote:

It's a lot easier, when all you might have is a hand held device,  
to be able to click though links to see even just the title of a  
document when someone asks "what do you think of BCP 58?"


 works for me :-)

Is there a document that describes how an RFC is admitted to the  
BCP/STD index?


RFC 2026?


Joe



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 63 On-line Survey

[Rob Evans]

> My problem is what "herring bone" seating layout is. I don't understand
> why the question is asked either. Why is it important whether people
> attended those sessions?

If you say "yes," it pops up another question asking if you preferred
it to the usual classroom style of seating.

Herringbone seating is where the rows either side of the aisle are at
an angle of about 120 degrees instead of 180 degrees.

Cheers,
Rob

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

BCPs and STDs

[Edward Lewis]

I was trying to find links from the www.ietf.org and 
www.rfc-editor.org pages that lead to indexes of BCPs and STDs.  I 
couldn't find any links.  If I know the RFC number I can find them 
via a few methods, and I am aware of search engines.


It's a lot easier, when all you might have is a hand held device, to 
be able to click though links to see even just the title of a 
document when someone asks "what do you think of BCP 58?"


Is there a document that describes how an RFC is admitted to the 
BCP/STD index?  I am not looking for a discussion on this list, just 
a reference.  Who has "ownership" of the list, is it part of the RFC 
editor function?

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 63 On-line Survey

[Stig Venaas]

On Wed, Aug 17, 2005 at 05:35:44PM +0200, [EMAIL PROTECTED] wrote:
> That question stymied me, so I just selected "No change."

I thought that was clear.

My problem is what "herring bone" seating layout is. I don't understand
why the question is asked either. Why is it important whether people
attended those sessions?

Stig

> 
> John
> 
> -- original message --
> Subject:  Re: IETF 63 On-line Survey
> From: Jari Arkko <[EMAIL PROTECTED]>
> Date: 08/17/2005 3:26 pm
> 
> Spencer Dawkins wrote:
> 
> > Would you prefer longer meetings or shorter meetings?
> > Shorter meetings with more overlaps
> > No change
> > Longer meetings with fewer overlaps
> >
> > means! I'm answering it, assuming that it refers to the one-hour 
> > sessions that sometimes get doubled-up into two-hour sessions, but if 
> > you mean something else, please let us know.
> 
> I interpreted it as having a short IETF meeting (e.g. mon-thu) but with lots
> of parallel WG meetings vs. longer IETF meeting (e.g. sun-fri) but with less
> parallel WG meetings.
> 
> So I guess that just shows how people have a different understanding
> of what was being asked.
> 
> --Jari
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 63 On-line Survey

[john . loughney]

That question stymied me, so I just selected "No change."

John

-- original message --
Subject:Re: IETF 63 On-line Survey
From:   Jari Arkko <[EMAIL PROTECTED]>
Date:   08/17/2005 3:26 pm

Spencer Dawkins wrote:

> Would you prefer longer meetings or shorter meetings?
> Shorter meetings with more overlaps
> No change
> Longer meetings with fewer overlaps
>
> means! I'm answering it, assuming that it refers to the one-hour 
> sessions that sometimes get doubled-up into two-hour sessions, but if 
> you mean something else, please let us know.

I interpreted it as having a short IETF meeting (e.g. mon-thu) but with lots
of parallel WG meetings vs. longer IETF meeting (e.g. sun-fri) but with less
parallel WG meetings.

So I guess that just shows how people have a different understanding
of what was being asked.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Marc Manthey]

On Aug 17, 2005, at 4:11 PM, Iljitsch van Beijnum wrote:


On 17-aug-2005, at 15:34, Marc Manthey wrote:


Just to be sure: what were talking about is that when a customer  
gets up in the morning and connects to www.ietf.org they get  
www.advertising-down-your-throat.de instead, right?


yes , thats exactly what it  does , they call it  "Portal-Guided  
Entrance" on port :80 and 443.


Does this work on port 443? I would assume the SSL security checks  
wouldn't accept this.


its  their  technolgie ,they call it  " ipass"  or something else
i guess it works ip adress based , another concern what someone posted,


 there have been changes too with DTAG.DE they changed
"my" DSLAM to 84.xxx.xxx.xxx and 84.xxx.xxx.xxx is still very new.
A lot of routers treat it as bogon.


thats bad!!


Of course United Internet
got that very same address range. They too do worry why some
ip addresses can no longer ftp, scp or VoIP.



so they  give you the ip adress that they  filter :-)

cheers

--
" The mind, once expanded to the dimensions of larger ideas,  never   
returns to its original size."


Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Iljitsch van Beijnum]

On 17-aug-2005, at 15:34, Marc Manthey wrote:

Just to be sure: what were talking about is that when a customer  
gets up in the morning and connects to www.ietf.org they get  
www.advertising-down-your-throat.de instead, right?


yes , thats exactly what it  does , they call it  "Portal-Guided  
Entrance" on port :80 and 443.


Does this work on port 443? I would assume the SSL security checks  
wouldn't accept this.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Marc Manthey]

On Aug 17, 2005, at 3:20 PM, Iljitsch van Beijnum wrote:


On 17-aug-2005, at 15:03, Brian E Carpenter wrote:



You can ask some pointed questions using RFC 4084 ("exactly which
of these descriptions applies to your service, and please show
me in the contract where you are allowed to change your service
without notice").  But I suspect that even free copies of
RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.



Just to be sure: what were talking about is that when a customer  
gets up in the morning and connects to www.ietf.org they get  
www.advertising-down-your-throat.de instead, right?


Maybe a nice lawsuit will do the trick. They are assuming the  
identities of others. That can't be legal.


yes , thats exactly what it  does , they call it  "Portal-Guided  
Entrance" on port :80 and 443.


regards

marcM.

--
"If women didn't exist, all the money in the world
would have no meaning."

Les Enfants Terribles
www.let.de





smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 63 On-line Survey

[Jari Arkko]

Spencer Dawkins wrote:


Would you prefer longer meetings or shorter meetings?
Shorter meetings with more overlaps
No change
Longer meetings with fewer overlaps

means! I'm answering it, assuming that it refers to the one-hour 
sessions that sometimes get doubled-up into two-hour sessions, but if 
you mean something else, please let us know.


I interpreted it as having a short IETF meeting (e.g. mon-thu) but with lots
of parallel WG meetings vs. longer IETF meeting (e.g. sun-fri) but with less
parallel WG meetings.

So I guess that just shows how people have a different understanding
of what was being asked.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Iljitsch van Beijnum]

On 17-aug-2005, at 15:03, Brian E Carpenter wrote:


You can ask some pointed questions using RFC 4084 ("exactly which
of these descriptions applies to your service, and please show
me in the contract where you are allowed to change your service
without notice").  But I suspect that even free copies of
RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.


Just to be sure: what were talking about is that when a customer gets  
up in the morning and connects to www.ietf.org they get  
www.advertising-down-your-throat.de instead, right?


Maybe a nice lawsuit will do the trick. They are assuming the  
identities of others. That can't be legal.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Frank Ellermann]

Roland Bless wrote:

> This breaks IMHO a lot of applications, e.g., DynDNS
> registrations of DSL routers

Some DynDNS clients allow to use port 8245 (JFTR, it's
clear that this isn't your point).

> Is there anything newer than RFC 2775 that one could
> give as strong technical advice to abandon that feature

Check out RfC 4084 (BCP 104) "full internet connectivity".
But I doubt that it helps, chapter 3 only says "MUST be
disclosed", they do this.

Maybe you find an appropriate MUST in the HTTP/1.1 RfC.

> I like to raise the awareness of the provider that this
> feature is _technically_ dangerous, though it may make a
> lot of sense for the marketing people...

Sure, it's also an opt-out scheme, just stating what it is
in public comparing it with similar features of say SpamCast
might help to "educate" them, otherwise many Web browsers
will soon offer to do a dummy HTTP GET on startup.  

Good luck, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 63 On-line Survey

[Spencer Dawkins]

IETF Chair wrote:


To assist the planning of future meetings, we ask you kindly to spend a
minute or two responding to the on-line survey at
   http://geneva.isoc.org/surveys/index.php?sid=4
Even if you did not attend IETF 63 in Paris, we would value your responses.
All responses will be treated anonymously, and a summary will be available
on-line.

Please respond by August 26 at the latest.

Thanks

   Brian Carpenter, IETF Chair
   Ray Pelletier, IETF Administrative Director 



Dear Brian and Ray - thank you for doing this survey - one question, though.

I have NO idea what



Would you prefer longer meetings or shorter meetings?
Shorter meetings with more overlaps
No change
Longer meetings with fewer overlaps


means! I'm answering it, assuming that it refers to the one-hour 
sessions that sometimes get doubled-up into two-hour sessions, but if 
you mean something else, please let us know.


Thanks,

Spencer


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Brian E Carpenter]

Roland,

You can ask some pointed questions using RFC 4084 ("exactly which
of these descriptions applies to your service, and please show
me in the contract where you are allowed to change your service
without notice").  But I suspect that even free copies of
RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.

   Brian

Roland Bless wrote:

Hi,

just yesterday a larger german DSL/Internet provider activated
- without a real notice - a feature as "field trial" in my city,
so that HTTP(S) requests of customers are redirected to their own
web portal (apparently using some soft state timeout).
I'm also aware of several other dial-up providers who do that.
This breaks IMHO a lot of applications, e.g., DynDNS
registrations of DSL routers (which would not be necessary
with IPv6 but that is another issue), automated Windows/Linux
updates, anti-virus database updates, RSS and presumably many
more. Though they sell it as a "service to
customers" (luckily you still can turn this feature off
if you know how to do it...), I see it as very dangerous
since automated security updates etc. will fail, i.e. they
even decrease the security of their cutomers! Is there
anything newer than RFC 2775 that one could give as
strong technical advice to abandon that feature and to
not turn it on for all other users?

Regards,
 Roland

P.S.: please don't comment that I should just switch
the provider in this case. I like to raise the awareness of
the provider that this feature is _technically_ dangerous,
though it may make a lot of sense for the marketing people...

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Stopping loss of transparency...

[Peter Dambier]

Roland Bless wrote:

Hi,

just yesterday a larger german DSL/Internet provider activated
- without a real notice - a feature as "field trial" in my city,
so that HTTP(S) requests of customers are redirected to their own
web portal (apparently using some soft state timeout).
I'm also aware of several other dial-up providers who do that.
This breaks IMHO a lot of applications, e.g., DynDNS
registrations of DSL routers (which would not be necessary
with IPv6 but that is another issue), automated Windows/Linux
updates, anti-virus database updates, RSS and presumably many
more. Though they sell it as a "service to
customers" (luckily you still can turn this feature off
if you know how to do it...), I see it as very dangerous
since automated security updates etc. will fail, i.e. they
even decrease the security of their cutomers! Is there
anything newer than RFC 2775 that one could give as
strong technical advice to abandon that feature and to
not turn it on for all other users?



Hi Roland,
I have seen the Heise forum is shaking up because of that. Today
it is GMX or United Internet but tomorrow it could be DTAG.DE and
in fact it is DTAG.DE who does offer this "service" to its clients
like United Internet. Obviously they (DTAG.DE) offered this
"service" as a trojan horse to get some of their T-online desserteurs
back. They did not only break software but they did break hardware too,
routers. Some of the end users are locked out. Switching off that
"service" means changing user id's. After that some routers did
not login again, neither using the old nor using the new user id.
I guess marketing is not amused.


Regards,
 Roland

P.S.: please don't comment that I should just switch
the provider in this case. I like to raise the awareness of
the provider that this feature is _technically_ dangerous,
though it may make a lot of sense for the marketing people...


In fact things like that did stop me from changing. My isp is
not the cheapest nor do they offer the best service but they are
so predictable. Normally you dont need to be afraid of changes
from burocrates. :)

Oh, yes there have been changes too with DTAG.DE they changed
"my" DSLAM to 84.xxx.xxx.xxx and 84.xxx.xxx.xxx is still very new.
A lot of routers treat it as bogon. Of course United Internet
got that very same address range. They too do worry why some
ip addresses can no longer ftp, scp or VoIP.

Introducing a new "service" was just a means of throwing sand
into their customers eyes and keeping them from seeing the
big picture.


Regards,
Peter and Karin Dambier
--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Stopping loss of transparency...

[Roland Bless]

Hi,

just yesterday a larger german DSL/Internet provider activated
- without a real notice - a feature as "field trial" in my city,
so that HTTP(S) requests of customers are redirected to their own
web portal (apparently using some soft state timeout).
I'm also aware of several other dial-up providers who do that.
This breaks IMHO a lot of applications, e.g., DynDNS
registrations of DSL routers (which would not be necessary
with IPv6 but that is another issue), automated Windows/Linux
updates, anti-virus database updates, RSS and presumably many
more. Though they sell it as a "service to
customers" (luckily you still can turn this feature off
if you know how to do it...), I see it as very dangerous
since automated security updates etc. will fail, i.e. they
even decrease the security of their cutomers! Is there
anything newer than RFC 2775 that one could give as
strong technical advice to abandon that feature and to
not turn it on for all other users?

Regards,
 Roland

P.S.: please don't comment that I should just switch
the provider in this case. I like to raise the awareness of
the provider that this feature is _technically_ dangerous,
though it may make a lot of sense for the marketing people...

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf