Subject: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs?

From: Rob Austein <[email-masked]>
Date: Wed, 09 Apr 2003 16:07:50 -0400

DNSSECbis Q-07:

   Should the DNSSECbis documents discuss use of preconfigured trusted
   DSs in addition to to preconfigured trusted KEYs?

Discussion:

   As currently written, the DNSSECbis documents (specifically,
   -protocol) only talk about how to establish a chain of trust
   starting with preconfigured trusted keys.  At least one member of
   the dnssec-editors team believes that this is just an oversight,
   since section 2.4.1 of -delegation-signer-13 specifically mentions
   the possibility of using DS RRs as a means of listing trusted keys
   in configuration files.

   Message from the DNSOP WG mailing list attached below for context.

   Miek has kindly volunteered to work with the editors on wording.

--[[message/rfc822]
Date: Tue, 08 Apr 2003 21:55:56 -0400
From: Rob Austein <[email-masked]>
To: [email-masked]
Subject: Re: preconfigured keys or ds's
References: <[email-masked]>
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>

At Mon, 31 Mar 2003 15:29:15 +0200, Miek Gieben wrote:
> 
> I would like to see the following documented, but I don't know for sure
> if it is a dnssec or dnsop issue:
> 
> The preconfigured keys for resolvers are large and are hard to compare
> and read (by humans). DS records on the other hand are much smaller
> and easier to handle. I think it would be better to preconfigure
> DS records in stead of zone keys for resolvers. This is also how
> my perl resolver works.

<hat dnsop-wg-co-chair=off dnssec-editors-team-member=off>

  This sounds like a reasonable implementation choice.

</hat>

> Where to put this? In the dnssec drafts or in a seperate dnsop BCP?

<hat dnsop-wg-co-chair=off dnssec-editors-team-member=on>

  The current DNSSECbis drafts don't talk about using trusted DS RRs
  as a starting point, only trusted KEYs.  Given the last paragraph of
  section 2.4.1 of draft-ietf-dnsext-delegation-signer-13.txt, this
  looks like an oversight (probably mine, since I was probably the
  last person to work on the relevant text in the DNSSECbis drafts).

  So the DNSSECbis spec needs fixing, and I don't expect anybody to
  argue against the fix, but for process reasons it'd be best to post
  an explanation to namedroppers first, so I'll do that.

</hat>

<hat dnsop-wg-co-chair=on dnssec-editors-team-member=off>

  Because of the above, at least part of this is a DNSEXT issue.

</hat>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Derek Atkins <[email-masked]>
Date: 09 Apr 2003 16:52:50 -0400

Effectively what you are saying is that you want to store
a hash of the trusted key rather than the key itself.
I'm not sure what I think about this.

On the face of it, it should work just fine.  However
you're now trusting the hash algorithm to root your
key.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Rob Austein <[email-masked]>
Date: Wed, 09 Apr 2003 17:13:59 -0400

> I'm not sure what I think about this.

Allow implementors the option of storing the hash instead of the key,
yes.  Implementors who prefer to store the key could still do so.

> you're now trusting the hash algorithm to root your

Yep.  We trust the same hash algorithm when following delegations, so
I doubt there's a serious threat here, but that's the issue.

---

From: Derek Atkins <[email-masked]>
Date: 09 Apr 2003 23:59:00 -0400

> yes.  Implementors who prefer to store the key could still do so.

Sorry, of course it provides the option...

> I doubt there's a serious threat here, but that's the issue.

I think that so long as users have the option then there is no problem.

-derek

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 10 Apr 2003 10:38:12 +0200

>    DSs in addition to to preconfigured trusted KEYs?

The idea has operational elegance. I also think that because of DS
having hash versioning and you rely on SHA1 hashes in algorithms 3 and
5 today there are no apparent crypto/security risks (But hey I'm no
cryptoguru).

What I do not like is that you loose the ability to verify directly
against the configured key and thus leave the KSK out of the apex
keyset. This is relevant in the context of Ihrens treshold validation
and root signing draft.

                           -----------------------

I am a little confused if having a keyset without the KSK is actually
allowed by the current specs (also see the thread starting with:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00752.html
)

In section 2 (signing) of the protocol doc there is a SHOULD:
   "For each private key used to create SIG RRs, there SHOULD be a
    corresponding KEY RR stored at the zone apex"

In section 5 it says:

  "An initial KEY RR can be used to authenticate a zone's apex KEY
   RRset.  To authenticate an apex KEY RRset using an initial key, the
   resolver MUST:

   1.  Verify that the initial KEY RR appears in the apex KEY RRset, and
       verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
       set to one.

   2.  Verify that there is some SIG RR which covers the apex KEY RRset,
       and that the combination of the SIG RR and the initial KEY RR
       authenticates the KEY RRset.  The process for using a SIG RR to
       authenticate an RRset is described in Section 5.2.
   "

The SHOULD in section 2 and the MUST in section 5 are IMHO
inconsistent.  There was some debate in the previous thread on how to
solve this inconsistency.

I've read sections 2.1 and 2.2 of RFC3090 and those do not seem to
exclude the use of a key that is not published in the zone itself.

In other words I am still confused, which is if it comes to specs a
bad sign.

Maybe the specs should be clarified to specifically allow or disallow
proof against the pre-configured key directly. I would choose for
allowing direct verification of signatures with pre-configured
keys.

(Hey Brian or Mark, what does the current BIND9 code do?)

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Miek Gieben <[email-masked]>
Date: Thu, 10 Apr 2003 11:33:11 +0200

[On 10 Apr, @10:38, Olaf wrote in "Re: DNSSECbis Q-07: Discuss pr ..."]
> 5 today there are no apparent crypto/security risks (But hey I'm no

crypto risks aside, I think it is a good to be able to manually check
that your preconfigured ds's are the right ones. 

> keyset. This is relevant in the context of Ihrens treshold validation

This should IMO be a MUST. A secure zone MUST have a key in the apex and a
resolver MUST check that.

grtz Miek

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 10 Apr 2003 11:20:56 -0400

>resolver MUST check that.

<DS editor hat on>
I agree with this, operationally life will be much simpler if the KSK
is in the key set.
 From the resolver perspective it can detect many different error conditions
and give more intelligent error messages. (example if you have one
KEY configured and that key rolls over, the resolver can now say:
"configured KEY for '.' missing, all other KSK keys signatures verify".)
The master server can use the presence of the KSK as loading precondition
and reject incorrectly configured zones.

As someone who has configured many trusted-keys even the best tools do not
protect you against corrupting large KEY records.
DS hash as trusted entry handle is much simpler for humans to manipulate
and check.

I think of it as feature that only few KSK can be in the root KEY set.
The dissemination of the trusted DS records for the root is where
a large group of keys can be used, as well as certificates.
Inclusion and update of the trusted root DS set is outside the
protocol, IMHO.

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Apr 2003 10:43:38 -0400

<with hat-in-hand>

Is preconfigured really a word?  Don't we just mean configured?

>>  > keyset. This is relevant in the context of Ihrens treshold validation

In the interest of interoperability, is it important whether the 
resolver has configured either the key or the hash of the key, or 
even a certificate containing the key?  It makes no difference to the 
on-the-wire DNS protocol.

The documents SHOULD NOT dictate the way in which the chain is 
anchored, just note that there MUST be a way to anchor chains.

>I agree with this, operationally life will be much simpler if the KSK

Yeah, but we must allow Randy to continue to say "I invite my 
competitors to operate this way."  I don't understand the need to 
over specify, why dictate one way of operating when there is no real 
need to do so?  All that we need to do is ensure that there's 
interoperability and a stable network.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 11 Apr 2003 10:58:07 -0400

I second the "let's not overspecify".  We might pass a point were we give
more people ammo to shoot themselves than security risks.   Not everyone
will want to have both a zone key and a KSK.  Those that will have both
might not want to put their KSK in the apex.

Scott
----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 11, 2003 10:43 AM
Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition
to preconfigured trusted KEYs?

---

From: Miek Gieben <[email-masked]>
Date: Mon, 14 Apr 2003 21:53:29 +0200

[On 11 Apr, @16:43, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."]
> anchored, just note that there MUST be a way to anchor chains.

yes, but this was/is somewhat related to the issue of having a key in 
the zone. We agreed(?) that a zone MUST have a key in it to be considered
secure.

If you say DS records can be used as a starting point you must also say
something about the use of a KSK in the zone. If there is no KSK there the DS
record can not be compared with it and your stuck.

If one only says there MUST be way to anchor chains, you leave this in the open.
I don't feel this is a overspecification,

grtz Miek

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Apr 2003 16:32:05 -0400

>the zone. We agreed(?) that a zone MUST have a key in it to be considered

Somewhat, but not quite, and I don't think this is related in this case. ;)

What data structure is used to hold the material a resolver considers 
absolutely trustworthy is what's at stake here.  I don't see the 
reason to specify the form of the data structure (i.e./e.g., key, 
hash, or certificate).

Of course, what is in the resolver's cache of absolutely trustworthy 
material has to relate to what is published in a zone - the KSK 
and/or ZSK.  But that's how you build the chain - what kinds of links 
are allowed and how the links are joined.

The data structure in the resolver is just the anchoring of the 
chain.  It only says how the first link in the chain is learned and 
accepted as "verifiably trustworthy" to the resolver.

>record can not be compared with it and your stuck.

Note that above I referred to key, hash, or certificate.  These three 
could be configured in the resolver using syntax equivalent to KEY, 
DS, or CERT RR's.  The three could also use other forms too, to the 
resolver it is not important as the configuration of the resolver is 
not subject to a protocol transfer.  (It's an "implementation 
detail.")

>If one only says there MUST be way to anchor chains, you leave this in the
>open.  I don't feel this is a overspecification,

Yeah -

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."

---

From: Miek Gieben <[email-masked]>
Date: Tue, 15 Apr 2003 10:18:06 +0200

[On 14 Apr, @22:32, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."]
> not subject to a protocol transfer.  (It's an "implementation 

ok, I can live with that. But what would you then like to see in
the DNSSEC Protocol Modifications draft, for instance section 5
starts like this:

5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, a security-aware
   resolver requires preconfigured knowledge of at least one
   authenticated KEY RR. 

I mean it is already in there...

grtz Miek

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Apr 2003 10:11:07 -0400

>I mean it is already in there...

The spirit is right, but I two issues with this.  One issue is from a 
wording point of view.  The other is from a specification 
(requirements) point of view.

If I were to write the above, I would say:

    For a security-aware resolver to be able to authenticate and verify
    the integrity of the data received through the use of the DNSSEC RR's,
    the resolver needs to have configured information from which to anchor
    the chain of trust.

I assume that "chain of trust" (or similar phrase) is defined 
elsewhere.  The reason I dropped the KEY RR is that it is possible 
that a resolver would be able to use the configured data to verify a 
SIG RR without consulting any KEY RR(s).  E.g., a CERT RR might be in 
the resolver's configuration data - which might identify the subject 
public key as the key also known as the "signer" and "footprint" in 
the SIG RR fields.

As far as a requirement:

     A security aware resolver MUST be capable of configuring security
     information that will enable the anchoring of a chain of trust. An
     implementation SHOULD NOT place any limits on the number of security
     anchors other than that necessitated by resource (e.g., memory)
     limitations.  An implementation MAY restrict the security anchors to
     one form, e.g., DS RR's, or MAY accept non-DNS data structures, e.g.,
     pkcs #? X.509 certificates.

(The examples I've chosen are quite arbitrary.  I mean not to slight those
who favor KEY RR or OpenPGP or whatever.)

As a document editor, I would include both passages - prose to 
explain and requirements to specify.

---

From: Derek Atkins <[email-masked]>
Date: 15 Apr 2003 11:51:06 -0400

> reason to specify the form of the data structure (i.e./e.g., key,

Actually, I do.  Zone A running servers from vendor A create the zone
information and want to supply an out-of-band method to their known
clients to authenticate their zone (such as a PGP-signed data object).
Clients of Zone A are running resolvers from vendors A, B, C, and D
and all need to be able to plug in the PGP-signed object (after the
PGP signature has been verified and removed) into their resolver's
"secure entry point database".

We need a standard way to doing this in order to solve this particular
scenario (and frankly I think this is going to be the common usage
scenario).

> not subject to a protocol transfer.  (It's an "implementation detail.")

I think I just explained why it is more than just an implementation
detail.  Certainly how it is stored _in core_ is an implementation
detail, but how it is configured externally needs to have an
equivalent on-the-wire format in order for the zone operators to send
the key material to the clients in a common format.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Apr 2003 13:05:25 -0400

>information and want to supply an out-of-band method to their known

"Out-of-band to DNS." - right?  DNSEXT is extensions to DNS, right?

>"secure entry point database".

This sounds like a security data management protocol.

>scenario (and frankly I think this is going to be the common usage

I strongly disagree - especially if "we" is the DNSEXT WG.

Certainly a resolver could support PGP-objects in some standard 
(whatever that means) specified way and also support X.509 
certificates according to some other standard specified way.  DNSSEC 
shouldn't restrict this choice by defining one of the other.

I grok that you want to have an easy way to manage security 
parameters cross-platform.  But "the" mechanism to do this is best 
solved in a constituency that is more interested in security 
operations.  (Cue the arguments behind IPSECKEY.)  DNS folks need not 
reinvent this - I'm sure other protocol WGs have studied this.  What 
about defining a new DNS security MIB and using SNMPv4?  (That's one 
approach.)

>the key material to the clients in a common format.

To me as a DNS protocol weenie, how you type in the security data is 
just an implementation detail.  E.g., I don't care a wit about 
whether your name server uses ASCII zone files and loads them into 
memory, pre-calculates all possible answers based on authoritative 
data, or even uses a mySQL back end - it matters not to the wire 
protocol.  The DNS specifications need to be fair and unbiased, no 
leaning towards any one way to do something - and there are many ways 
we could go about configuring security meta-data.

---

From: Derek Atkins <[email-masked]>
Date: 15 Apr 2003 14:00:16 -0400

Ed, I think you misunderstood what I was saying...

> This sounds like a security data management protocol.

And as such DNSEXT cannot ignore it.  You cannot just toss it over the
fence -- this is exactly why each and every RFC is required to have a
Security Considerations section -- everyone needs to think about
security.

> shouldn't restrict this choice by defining one of the other.

You clearly misunderstood what I meant, and nowhere did I state OR
imply that DNS software needs to implement PGP objects.  I uses PGP as
an example, and I'm sorry if that confused you.  Just to make sure
it's absolutely clear, let me enumerate a bunch of ways this could be
done (and note to the pedantic that this list is NOT exhaustive):

        HTTPS GET
        PGP protected file
        S/MIME protected file
        CD-ROM you get from your local IT Admin
        Barcode printed in the NYT
        SNMP MIB (just to use your example)
        
Yes, you are absolutely correct that we cannot, indeed MUST NOT,
mandate any particular _method_ of transmission of data.  However,
that does NOT imply that we should not standardize on the message
being transmitted and protected through all these methods.

To repeat myself, I'm specifically talking about the data format, not
the transmission and/or protection method.  In short: we need a way so
to create a secure-entry-point data object that can be read by any
implementation.  This data object can be protected by PGP, S/MIME, or
Telepathy for all I care...  But I want a data object that can be read
by all resolvers (just like we have a zone-file format that can be
read by all servers).

> just an implementation detail.  E.g., I don't care a wit about whether
> your name server uses ASCII zone files and loads them into memory,
> pre-calculates all possible answers based on authoritative data, or
> even uses a mySQL back end - it matters not to the wire protocol.  The
> DNS specifications need to be fair and unbiased, no leaning towards
> any one way to do something - and there are many ways we could go
> about configuring security meta-data.

Then explain why the DNS Protocol Specification talks about zone file
formats for each of the DNS Resource Records.  We already standardize
a file format for zones.  Why be hypocritical and claim that defining
zone-file formats is reasonable but defining the file format for
secure entry points is not reasonable?

Note that, to make it clear, all I'm saying is that we should
standardize the secure entry point data; I am _NOT_ suggesting that we
standardize the METHOD of transmission or protecting said data.  I
think that is completely within the purview of DNSEXT, just as it it
within our purview to define the zone file format.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Apr 2003 14:44:45 -0400

>Security Considerations section -- everyone needs to think about

Ignore it, no.  But the DNS specification ought not to overstep its 
bounds.  If we were to try to bloat the feature set in the DNSSEC 
protocol this way, we will incur more delay in trying to get the 
documents back to Proposed Standard - if we do the job right.  (As in 
research and discuss these points and then see how these points 
impact all the previously agreed-to points already in the document.)

Note that TSIG and SIG(0) aren't in the DNSSEC documents either. 
They are part of the problem, but are not integral to DNSSEC.  How 
the anchors are implemented shouldn't be either.  DNSSEC just assumes 
that resolvers have anchors (hence the MUST in my previous message).

>being transmitted and protected through all these methods.

You have me at a loss here.  Completely.  Are you saying that we 
shouldn't agree on whether we use TCP or UDP so long as we use X.509? 
(All examples are arbitrary.)

>by all resolvers (just like we have a zone-file format that can be

It would be nice if all the world worked one way.  But there's a cost 
to achieving it.  The reason I don't want to tie down one method now 
is that I am not aware of a solution that is the best now and will be 
the best in two years.  If you insist on trying to find that 
solution, I for one will not participate in the debate - because that 
would be all that I would be doing, not gaining hands on experience, 
refining what I think is the situation to solve for.

Can "all" name servers read the BIND file format?  I didn't think it 
was required.

>secure entry points is not reasonable?

The hypocrisy here is not mine.  I have frequently balked at textual 
definitions being part of the standard.  (Ask the chairs.)  On the 
other hand, it is good to have textual conventions for the sake of 
documentation (and that's all).  A name server implementation would 
not be discounted by me if it did not conform to the text 
representations.

>within our purview to define the zone file format.

Well, as you can see, I don't support defining textual conventions 
for DNS, so I don't agree with this last portion of your message.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 15 Apr 2003 15:04:38 -0400

> (All examples are arbitrary.)

Sort of.  I'm saying that "we don't need to agree on whether we use
TCP, UDP, HTTPS, PGP-over-email, or unencrypted/unsigned CDRoms, so
long as we agree that we should use the KEY or DS format records for
the secure entry point."  We don't need to agree on how the SEP data
gets to the resolver.  We don't need to agree on how the SEP data is
authenticated by the end user (or the resolver).  However, we should
agree on what the SEP data should be that is fed to the resolver.

Note that I see no reason to actually use X.509 certs (or PGP Certs,
or indeed ANY certificate) for the SEP data.  The nice thing about
pre-configured SEPs is that you don't need to verify them too -- they
are trusted.  This means can use raw keys just as easily as you can
use self-signed certificates.  Using anything but a self-signed
certificate is just silly, because it implies that you _don't_ have
the entry point -- because you need the certificate signer to verify
the certificate....

Personally, I recommend we standardize on "KEY", and "DS" (and maybe
CERT) record formats for the SEP data.  Just like many resolvers use a
root.hints file which contain a set of NS and A records; we can create
an SEP.hints file which contain a set of KEY, DS, and maybe CERT
records (although I'm not sure how the CERT record would/could be
used).  Then we could just use the standard master-file format and be
done with it.

Note that I don't say how the resolver gets this hint file, how how it
is verified.  I'm just talking about the contents.

> Can "all" name servers read the BIND file format?  I didn't think it

RFC 1035 is unclear -- it's before the use of MUST/SHOULD/MAY -- but
my interpretation is that they MUST understand the master file format
but they may choose not to use it.  I haven't followed up with the
updated RFCs to see if that's made more clear.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Apr 2003 15:30:37 -0400

At 15:04 -0400 4/15/03, Derek Atkins wrote:
>gets to the resolver.

What do you mean by SEP data?  What do you mean "gets to" the resolver?

My assumption is that DNSSEC is about making the world safe for the 
resolver.  It needs security anchor data to do this - that's a 
requirement.  How the anchor data gets there and in what form is out 
of scope for the DNSSEC document.

I think that trying to specify the how a resolver's configuration is 
done is on par with that of a name server - we don't specify the 
"named.conf" file.

>CERT) record formats for the SEP data.  Just like many resolvers use a

Would an resolver implementation choosing to use X.509 certificates 
be non-interoperable with the implementation you build to your 
suggestion?

>used).  Then we could just use the standard master-file format and be

Have you read Johan Ihren's drafts?  Do you mean to say that the 
DNSOP WG gets to have no say in the matter?  You seem to want to 
restrict operational choices by over-specifying the underlying 
protocol.

>updated RFCs to see if that's made more clear.

What do you mean by "understand?"  (Upon what section of 1035 do you 
base your interpretation?)

BIND parses it's master file format and stores data accordingly.  Why 
would I implement (such) a parser if my server never read text files?

---

From: Miek Gieben <[email-masked]>
Date: Wed, 16 Apr 2003 13:53:30 +0200

[On 15 Apr, @21:30, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."]
> of scope for the DNSSEC document.

it should at least not be specified in the dnssec-protocol draft. But I
can not stop myself from thinking that stuff like this should be written
down (somewhere)...

grtz Miek

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Apr 2003 09:28:33 -0400

>can not stop myself from thinking that stuff like this should be written

Right.

Finding the "someplace else" is hard - DNS has already struck out 
once with a MIB definition.

I'm not against the effort.  Based on past history, my prediction is 
that such an effort faces many challenges before accomplishing 
anything.  My first advice to anyone trying such an effort - research 
the previous efforts and see where they stumbled.  ("Past is 
prologue"-- unknown to me.)

This, of course, has no bearing on any individual implementor's 
desire to experiment on their own.  Running code is always welcome. 
Sometimes just being first means you get to set the table, it could 
mean that you're the one who gets shot in the back.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer