Working Group
To:
"Transport Layer Security (TLS) Renegotiation Indication Extension, IETF
TLS
Working Group draft that addresses the vulnerability."
Where "IETF TLS Working Group" is hyperlinked to
http://www.ietf.org/dyn/wg/charter/tls-charter.html
That would help people who do not have a clue who the IETF or the TLS WG
draft standard that addresses the vulnerability."
To:
"Transport Layer Security (TLS) Renegotiation Indication Extension, IETF TLS
Working Group draft that addresses the vulnerability."
Where "IETF TLS Working Group" is hyperlinked to
http://www.ietf.org/dyn/wg/charter/tls-charter.html
That would help people who do not have a clue who the IETF or the TLS WG or
is that this document has been the result of a lot of work (including
the work of the many peple that reviewed the CPNI version of the
document), and that the IETF should take this chance to work and publish
something on the subject.
The chairs of the TCPM Working Group of the IETF are currently polling
the WG for input about this document. It would be great if you could
voice your opinion about whether the TCPM should take this document on,
and also whether you would be willing to review this document. (Bellow
you'll find a copy of the TCPM chairs' poll)
1948, and takes the ISN generation algorithm originally proposed in
that document to Standards Track, formally updating RFC 793.
[STANDARDS-TRACK]
This document is a product of the TCP Maintenance and Minor Extensions
Working Group of the IETF.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
This document describes current issues relevant to the implementation
and use of TCP urgent data, aims to change the IETF specifications so
that they accommodate what virtually all implementations have been doing
wrt urgent data.
The TCPM working group of the IETF is currently deciding whether to
adopt this document as a working group item, so that your input will be
very much appreciated.
To voice your opinion, please send it to tcpm@ietf.org, and CC me
(fernando@gont.com.ar), so that I make sure that your post makes it to
TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP),
Datagram Congestion Control Protocol (DCCP), and RTP (provided that
the RTP application explicitly signals the RTP and RTCP port
numbers). This memo documents an Internet Best Current Practice.
This document is a product of the Transport Area Working Group Working
Group of the IETF.
BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
> By the way, I don't think it is a good idea to disallow any Extension
> Headers in ND-Messages,
Consensus at the relevant IETF working-group (6man) seems to be to only
ban the Fragment Header (when SEND is not employed).
A more conservative approach would be to simply require that the
upper-layer header be present in the first fragment. (i.e., that the
first fragment contains all the information that you need to apply an ACL).
2010/03/10: Public disclosure
VI. Credit
This vulnerability has been discovered by Jakob Lell from the
TU Berlin computer security working group (AGRS).
http://www.agrs.tu-berlin.de/parameter/en/
A copy of this advisory is also available on the following page:
Unfortunately :(
>> By the way, I don't think it is a good idea to disallow any Extension
>> Headers in ND-Messages,
>
> Consensus at the relevant IETF working-group (6man) seems to be to only
> ban the Fragment Header (when SEND is not employed).
I'd like to discuss this further, there are many options and I really
like to read other's opinions on that. Disallowing Fragmentation
Headers might break some stack implementations (but hopefully only in
some situations). On the other hand, (virtually) reassembling IPv6
Internet-Draft is available at:
http://www.gont.com.ar/drafts/ip-security/index.html (and of course it's
also available at the IETF I-D repository).
The Internet-Draft I published was aimed at the OPSEC WG. And the Working
Group is right now deciding whether to accept this document as a WG item.
This is certainly a critical step. Having the OPSEC WG accept this document
as a WG item would guarantee to some extent that the IETF will do something
about all this, and would also somehow set a precedent in updating the
specifications of core protocols and/or providing advice on security
aspects of them.
ScreenOS has several DOS issues in their IPv6 implementation btw
>> By the way, I don't think it is a good idea to disallow any Extension
>> Headers in ND-Messages,
>
> Consensus at the relevant IETF working-group (6man) seems to be to only
> ban the Fragment Header (when SEND is not employed).
not allowing ANY extension headers for NDP and RA is the way to go. But
of course, doing this might break future features. Thats the reason that
only the fragment header is planned to be banned. Networking people
timestamps". The I-D is available at:
http://tools.ietf.org/pdf/draft-gont-timestamps-generation-00.pdf
I have also authored a related I-D, entitled "Reducing the TIME-WAIT
state using TCP timestamps" which has already been accepted as a wg
item of the TCPM working group of the IETF. This one is available at:
http://tools.ietf.org/pdf/draft-ietf-tcpm-tcp-timestamps-00.pdf
Any comments will be more than welcome (in particular, about the
timestamps generation one).
This may be a little off-topic, but hopefully still of interest to this
audience,
Last Friday I had the opportunity to moderate a panel - Political
Phishing - A Threat to the 2008 Campaign? - held as part of the
Anti-Phishing Working Group eCrime Researchers Summit hosted by Carnegie
Mellon CyLab in Pittsburgh, PA. Our panelists were Rachna Dhamija from
Harvard University, Chris Soghoian from Indiana University , and Pat
Clarke of Jackson/Clark Partners. We had some great discussion on the
potential impact of Internet-borne threats to the upcoming US
Presidential Election.
>>> By the way, I don't think it is a good idea to disallow any Extension
>>> Headers in ND-Messages,
>>
>> Consensus at the relevant IETF working-group (6man) seems to be to only
>> ban the Fragment Header (when SEND is not employed).
>
> not allowing ANY extension headers for NDP and RA is the way to go. But
> of course, doing this might break future features. Thats the reason that
> only the fragment header is planned to be banned. Networking people
Jakob Lell from the TU Berlin computer security working group (
http://www.agrs.tu-berlin.de/v-menue/ag_rechnersicherheit/parameter/en/
) has discovered multiple vulnerabilities in several ATEN IP KVM
Switches.
Affected products:
- ATEN KH1516i IP KVM Switch (browser firmware version 1.0.063)
- ATEN KN9116 IP KVM Switch (firmware version 1.1.104)
- Aten PN9108 Power over the NET (only CVE-2009-1477)
|
