On Sun, Sep 30, 2007 at 10:32:39PM -0600,
Danny McPherson <[EMAIL PROTECTED]> wrote
a message of 51 lines which said:
> Section 4's reference to BCP 84, in part, creates a false sense of
> useful action on part of the operator,
This could be said of all the parts of the I-D which mentions non-
Hi David, and thanks for your review. Inline:
> As such, the whole document is a security consideration. The
> vulnerability appears well-documented, and the guidelines for handling
> the deprecated RH0 are clear.
>
Good.
> I have a few comments
> 1) RH0 really is something we do not want to
Brian E Carpenter wrote:
IANAL, but it's my understanding that the prominently displayed Note Well
text already serves this purpose. The real sanction can only be having
a patent struck down by the courts due to intentional failure to
disclose it; all the IETF can do is to make its rules clear
Hi, Dave,
Just to make sure I'm breathing the same atmosphere you are ...
Are you suggesting initial publication of RFCs as Historic?
I have some opinions about that, but wanted to make sure what you are
suggesting before I start typing...
Spencer
The only issue that occurs to me is the dif
On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:
The Introduction seems a bit defensive in stating that the DOS attacks
are not due to any flaw in the design of DNS or its implementations.
While the blame for the attacks lies with the attackers, some a
Spencer Dawkins wrote:
Hi, Dave,
Just to make sure I'm breathing the same atmosphere you are ...
Are you suggesting initial publication of RFCs as Historic?
No (though I think DomainKeys was just initially published that way, albeit
for a very different and benign reason; kinda amusing to
On Oct 1, 2007, at 10:10 AM, Jeffrey Hutzelman wrote:
No; the blame for an attack _always_ lies with the attacker, not
the victim. While I certainly wish more network providers would
implement BCP 38, those who fail to do so are not to blame for the
bad acts of others.
Given the realit
Hello,
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
What a timely thread.
I've recently concluded that we need an extension to getaddrinfo() along
these lines, but I'm looking for somewhat tighter and more generic
semantics.
My proposal is to add an AI_SECURE_CANONNAME flag with the following
semantics:
- it MUST be used with AI_CANONNAME
- if
On Oct 1, 2007, at 1:52 AM, Stephane Bortzmeyer wrote:
On Sun, Sep 30, 2007 at 10:32:39PM -0600,
Danny McPherson <[EMAIL PROTECTED]> wrote
a message of 51 lines which said:
Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator,
This could
Post-posting additional thoughts:
Dave Crocker wrote:
2. Rather, the label says something about community consensus. If a
later disclosure alters that consensus, then of course the community
should re-label the thing, to take it off standards track.
Although this should be check with an a
Hi. I opened a ticket with the secretariat a few weeks ago
complaining that I cannot reach www.ietf.org using a teredo address
either allocated through the Microsoft Teredo server or the Debian
teredo server.
This is annoying because glibc's source address selection algorithm
seems to prefer te
I can work on that.
Regards,
Jordi
> De: Sam Hartman <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Mon, 1 Oct 2007 13:50:00 -0400 (EDT)
> Para:
> Asunto: Would someone help the secretariat figure out why they cannot route to
> teredo addresses?
>
>
>
> Hi. I opened a ti
> What a timely thread.
>
> I've recently concluded that we need an extension to getaddrinfo() along
> these lines, but I'm looking for somewhat tighter and more generic
> semantics.
>
> My proposal is to add an AI_SECURE_CANONNAME flag with the following
> semantics:
do not try to imple
> As for the TSIG or SIG(0) recommendation, I'm not sure what
> the numbers are for client support today, but I suspect it's at
> best an negligible sample.
Well all Windows XP/2003/Vista boxes can be configured to
support TSIG, with free software, if not natively.
All Li
On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote:
As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.
Well all Windows XP/2003/Vista boxes can be configured to
support TSIG, with
>
>
> On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
>
> >> The Introduction seems a bit defensive in stating that the DOS attacks
> >> are not due to any flaw in the design of DNS or its implementations.
> >> While the blame for the attacks lies wit
> > It does, but normally only responses which are too long for UDP
> > require the use of TCP. A recursive nameserver could mitigate this
> > type of attack by lowering the maximum response size it is willing
> > to send via UDP, forcing the use of TCP and thus a three-way
> > handshake
>
>
> On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson
> <[EMAIL PROTECTED]> wrote:
>
> > Note that in real deployments just this behavior has broken things
> > on occasion, as many firewall and other such policy application points
> > assume things like DNS resolution will only b
Jun-ichiro itojun Hagino wrote:
>> What a timely thread.
>>
>> I've recently concluded that we need an extension to getaddrinfo() along
>> these lines, but I'm looking for somewhat tighter and more generic
>> semantics.
>>
>> My proposal is to add an AI_SECURE_CANONNAME flag with the following
>> s
> On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote:
>
> >
> >> As for the TSIG or SIG(0) recommendation, I'm not sure what
> >> the numbers are for client support today, but I suspect it's at
> >> best an negligible sample.
> >
> > Well all Windows XP/2003/Vista boxes can be configured to
> >
Hi Tobias,
Many thanks for your review. Please see inline for my thoughts on your
observations.
On 10/1/2007 9:39 AM, Tobias Gondrom wrote:
Hello,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.
Jun-ichiro itojun Hagino wrote:
I've recently concluded that we need an extension to getaddrinfo() along
these lines, but I'm looking for somewhat tighter and more generic
semantics.
My proposal is to add an AI_SECURE_CANONNAME flag with the following
semantics:
> >> I've recently concluded that we need an extension to getaddrinfo() along
> >> these lines, but I'm looking for somewhat tighter and more generic
> >> semantics.
> >>
> >> My proposal is to add an AI_SECURE_CANONNAME flag with the following
> >> semantics:
> >
> > do not try to implement po
> >>it can be application-specific, without application modification.
> >>check out "systrace" by Niels Provos.
> >>
> it's useful but it really isn't flexible enough to remove the need for
> applications to be able to specify policies.
i wonder how many command line options w
Jun-ichiro itojun Hagino wrote:
it can be application-specific, without application modification.
check out "systrace" by Niels Provos.
>> it's useful but it really isn't flexible enough to remove the need for
>> applications to be able to specify policies.
>
See
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-02.txt
.
Donald
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Stephen Hanna
Sent: Monday, September 24, 2007 3:52 PM
To: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PR
Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez écrit :
> Hi. I opened a ticket with the secretariat a few weeks ago
> complaining that I cannot reach www.ietf.org using a teredo address
> either allocated through the Microsoft Teredo server or the Debian
> teredo server.
>
> This is
28 matches
Mail list logo
