Hello,
Section 7.1 of draft-ietf-enum-3761bis-04 is about DNS Security. One
sentence caught my attention:
"Because of these threats, a deployed ENUM service SHOULD include
mechanisms to ameliorate these threats."
My reading of that is that a deployed ENUM service should include
mechani
At 12:22 03-06-2009, Sam Hartman wrote:
I appreciate the work that has gone into this document. People have
worked hard to find examples, cases and even pithy
sayings/architectural principles from many areas of the IETF. The
document tries to be broad and to look at a lot of options. I think
t
Sam,
Thanks for posting your review. It caused me to have a look at the
document, because I've been considering writing something of a missive
on my own. I have to say that I enjoyed reading this draft up to about
Section 3, and then I came to some problems. I'll spell those out in a
separ
On 4 Jun 2009, at 04:06, Mark Andrews wrote:
In message >, Sabahattin Gucukoglu writes:
The problem is this: the authoritative servers for a domain can
easily
never be consulted for DNS data if the resource being looked up
happens to be available at the parent zone. That is,
bigbox.example.net
Bill Manning wrote:
> i think the distinction here might be characterised by
> the use of terms:
>
> -channel security
Don't try to confuse the terminology.
With the terminology of "channel", the paper addresses the issue
that security by channels between zones or zone admini
In message , Sab
ahattin Gucukoglu writes:
> ... it's that, or my reading of RFC 2181 has gone horribly wrong.
>
> The problem is this: the authoritative servers for a domain can easily
> never be consulted for DNS data if the resource being looked up
> happens to be available at the parent z
... it's that, or my reading of RFC 2181 has gone horribly wrong.
The problem is this: the authoritative servers for a domain can easily
never be consulted for DNS data if the resource being looked up
happens to be available at the parent zone. That is,
bigbox.example.net's address and the
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-geopri
I was assigned this document as a secdir review.
I'm not sure I have any comments in that capacity.
However, I do have significant comments on the last call of this document.
I appreciate the work that has gone into this document. People have
worked hard to find examples, cases and even pithy
sa
On Tue, 26 May 2009, The IESG wrote:
- 'IANA Registration of Enumservices: Guide, Template and IANA
Considerations '
as a Proposed Standard
This is an ops-dir review. I'm only superficially familiar with ENUM,
so take the comments with a grain of salt. I did not see major issues
with t
On Tue, Jun 02, 2009 at 10:38:28PM +0900, Masataka Ohta wrote:
> Christian Huitema wrote:
>
> >>That is, security of DNSSEC involves third parties and is not end
> >>to end.
>
> > That is indeed correct. An attacker can build a fake hierarchy of
> > "secure DNS" assertions and try to get it accep
Christian Huitema wrote:
> NAT routers come to mind. DNSSEC
> is immune to such attacks, a big advantage in practice.
I'm afraid DNSSEC and some NAT interact terribly.
> Also, it is actually possible to improve on DNSSEC by introducing
> additional knowledge. If two domains have an establish re
12 matches
Mail list logo
