Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs

From: [email-masked] (Julien Laganier)
Date: Wed Nov 10 13:25:00 2004

Hi folks,

I suggest that we resolve this issue as Erik/Pekka suggested during 
the meeting:

1) Store multiple IPs and HIs in a 'flat' manner in the DNS.

2) If a DNS query returns several IPs and HIs, then the node should 
just pick one of the locator and initiate towards it, and then 
validate the HI returned in R1 against the set it queried the DNS.

If everybody agrees, we need to work out the details, though...

Suppose there's two nodes, node-A and node-B, using the same FQDN, but 
each one has an IP (resp. IP-A and IP-B) and a HIT (resp. HIT-A and 
HIT-B). An initiator querying DNS for FQDN will get:

FQDN A IP-A
FQDN A IP-B
FQDN HIPHI HIT-A HI-A
FQDN HIPHI HIT-B HI-B

But then if it sends an I1 to (IP-B,HIT-A), node-B will receive this, 
but probably drop it as HIT-A doesn't belongs to it.

An easy solution is to require an initiator to initiate in 
Opportunistic Mode when several HIs are returned in a DNS lookup, and 
then have it validate the Responder HIT returned in R1 against the 
set of returned HITs.

In the previous example, that would means that initiator sends I1 to 
(IP-B, HIT-0), and gets back an R1 from (IP-B, HIT-B), then verifies 
that HIT-B belongs to the set of returned RRs.

I believe such behavior belongs to the base spec document, not to the 
DNS extension spec, but I'm not 100% sure...

What do you think? Thanks,

--julien

---

From: [email-masked] (Lars Eggert)
Date: Wed Nov 10 13:50:01 2004

This is a cryptographically signed message in MIME format.

--------------ms080501090002090700020605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> If everybody agrees, we need to work out the details, though...

I need more time to digest all the implications of this proposal, but my 
gut feeling is that I don't like this scheme. Here's why.

Basically, the mapping is from 1 FQDN into N HITs, each 1 of those HITs 
maps into M IP addresses. (I think this is what the outcome of the API 
discussion at the last IETF was, right?)

The question now is how we fit these two bindings into the current DNS.

The proposal you mention basically maps each FQDN into an unstructured 
set of both its associated IP addresses and HITs, and then uses a new 
protocol to figure out which HIT goes with which IP addresses.

This seems awfully complex, especially considering that the RG currently 
seems to lean towards relocating the HIT-to-IP binding into a second 
resolution system, maybe based on DHTs.

A much simpler stopgap may be to simple declare that until we have the 
support infrastructure in place, we mandate a 1:1 binding from FQDNs to 
HITs. Would we lose any critical functionality with this?

Another more complex - but also more powerful - approach may be to 
create a second DNS tree for HITs, i.e., simulate the eventual DHT 
lookup service using the DNS. Under this approach, you'd go to the DNS 
twice to initiate communication, once to look up the HITs that go with a 
FQDN, and a second time to look up the IP addresses that go with the one 
HIT you picked from the first result.

What does the group think of this?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------ms080501090002090700020605
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080501090002090700020605--

---

From: [email-masked] (Julien Laganier)
Date: Thu Nov 11 09:33:01 2004

On Wednesday 10 November 2004 21:01, Lars Eggert wrote:
> Julien Laganier wrote:
> > I suggest that we resolve this issue as Erik/Pekka suggested
> > during the meeting:
> >
> > 2) If a DNS query returns several IPs and HIs, then the node
> > should just pick one of the locator and initiate towards it, and
> > then validate the HI returned in R1 against the set it queried
> > the DNS.
> >
> I need more time to digest all the implications of this proposal,
> but my gut feeling is that I don't like this scheme. Here's why.
>
> Basically, the mapping is from 1 FQDN into N HITs, each 1 of those
> HITs maps into M IP addresses. (I think this is what the outcome of
> the API discussion at the last IETF was, right?)
>

Actually I thought we can't fit Type 1 HIT to IP address mapping 
anywhere with the current WG charter; DNS doesn't allow to store flat 
identifiers, and DHT stuff belongs to the RG.

> The proposal you mention basically maps each FQDN into an
> unstructured set of both its associated IP addresses and HITs, and
> then uses a new protocol to figure out which HIT goes with which IP
> addresses.

>From my personal perspective, this is not a new protocol, but rather 
the same opportunistic mode we already have, augmented/ameliorated by 
using stuff which was put in the DNS, buying us as much security as 
non-opportunistic mode. 

> This seems awfully complex, especially considering that the RG
> currently seems to lean towards relocating the HIT-to-IP binding
> into a second resolution system, maybe based on DHTs.

I don't feel it is complex, rather I found this solution one of the 
simplest we can have with the current WG charter items. After all it 
is just saying to run opportunistic mode if several HIs/IPs are bound 
to a single FQDN. But perhaps I'm just plain wrong... 

Also notes that the current base spec allows to sends multiple I1 in 
parallel, so you MAY initiate to multiple locators, then presumably 
get multiple R1s from each of the available HIs, allowing you to pick 
the one you want. 

> lookup service using the DNS. Under this approach, you'd go to the
> DNS twice to initiate communication, once to look up the HITs that
> go with a FQDN, and a second time to look up the IP addresses that
> go with the one HIT you picked from the first result.

This would work, but only for Type 2 HITs which you can lookup in the 
DNS (using the HIT.ARPA reverse tree).

Others?

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Thu Nov 11 14:45:01 2004

> protocol to figure out which HIT goes with which IP addresses.

There is no need for a new protocol.  Just trying out repeatedly or 
using
opportunistic mode is enough.

> currently seems to lean towards relocating the HIT-to-IP binding into 
> a second resolution system, maybe based on DHTs.

Actually, IMHO, what Erik and I proposed is the *simplest* possible way
of doing this without introducing new infrastructure.

> support infrastructure in place, we mandate a 1:1 binding from FQDNs 
> to HITs. Would we lose any critical functionality with this?

That was ruled out as wrong semantics at the WG meeting.

> lookup service using the DNS.

That would be awfully complex, and IMHO not worth the effort.

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Thu Nov 11 14:47:01 2004

> get multiple R1s from each of the available HIs, allowing you to pick

Right.  Alternatively, you can just send multiple I1s to the same
IP, but with different HITs, if you please.

--Pekka

---

From: [email-masked] (Lars Eggert)
Date: Thu Nov 11 15:04:00 2004

--------------ms080403040405020301010106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Pekka,

don't get me wrong, I'm not strongly opposed to the proposed approach.

I'm raising these questions - this one, as well as the one about teredo 
during the PATH discussion - to help us more fully evaluate all options 
as we go for forward. In my view, we as a group have a tendency to go 
for specific implementation approaches a little too quickly; some more 
vetting may be useful.

Pekka Nikander wrote:
> There is no need for a new protocol.  Just trying out repeatedly or using

It's a change not to the HIP protocol on the wire but to the state 
machines that exchange these messages.

> That was ruled out as wrong semantics at the WG meeting.

I'd agree that the semantics are *limited*, because the approach can't 
support hosts that have multiple identities, but I wouldn't call them wrong.

Would we lose any critical functionality, i.e., would we lose support 
for a killer app without supporting multiple identities per host from 
the beginning?

> That would be awfully complex, and IMHO not worth the effort.

Well, we're creating a second tree for HIT-to-FQDN reverse lookups anyway...

Lars

--------------ms080403040405020301010106

--------------ms080403040405020301010106--

---

From: [email-masked] (Pekka Nikander)
Date: Thu Nov 11 16:01:01 2004

Lars,

> I'm raising these questions - this one, as well as the one about 
> teredo during the PATH discussion - to help us more fully evaluate all 
> options as we go for forward. In my view, we as a group have a 
> tendency to go for specific implementation approaches a little too 
> quickly; some more vetting may be useful.

Fair enough.  But we must understand that such an attitude also slows 
you down, and I don't know if we need to slow down as long as we are 
doing experimental documents.  IMHO, we are slow enough already now.  
But maybe I am more impatient that most people are.

As long as we are not going for any standards track documents, I don't 
think that we have to be that specific what to "endorse", as we are not 
actually endorsing anything.  In my mind, the most important things are

   - keep things simple, and
   - get things out to get operational experience.

As we are chartered now, the only path to standards track documents is 
to complete the research group experiment report, and that requires 
real life data.  I am hoping that we could get that data starting from 
the next year, and I still hope that we could complete the experiment 
in 2006.  Or at least complete it in the sense that we get the 
experiment report written and submitted to the IESG.

What comes to this particular case, I am all for *simplicity* here.

>> There is no need for a new protocol.
>

Well, yes, but I don't see that as a large change.  But it may require 
a change to the base spec, I agree.

>>> A much simpler stopgap may be to simple declare that until we have 
>>> the support infrastructure in place, we mandate a 1:1 binding from 
>>> FQDNs to HITs. Would we lose any critical functionality with this?

Well, it starts to sound like that you weren't in Monday's meeting.  In 
the working group meeting on Monday I explicitly tried to propose that 
we mandate that there can be only one HIT per a domain name.  Lots of 
folks, including Christian Huitema, Keith Moore, and 3-5 others whom I 
don't remember or whose name I don't know, objected.  They explicitly 
told us that that would be the wrong semantics, that would have to be 
taken to the DNSEXT working group, and we just can't do that in the HIP 
WG.

Actually we spend large fraction of the WG time on this.  As far as I 
understood, the clear consensus in the room was the flat semantics.  
That is, if you have multiple HITs associated with the domain name, 
they must be understood as *equivalent*.  It doesn't matter which one 
you use.  You can use any.  Hence, if you connect to one of the 
locators associated with the domain name, you must accept any of the 
HITs that you got.

Of course, anything discussed at the face-to-face meeting is subject to 
further discussion on the mailing list, but in this particular case I 
don't see what we would get.  If we define something else, it is highly 
likely that we get back to this at the next IETF, or at least when the 
document goes to the IESG.

> Well, we're creating a second tree for HIT-to-FQDN reverse lookups 

Are we?  I wasn't aware of that.  In which draft?

--Pekka

---

From: [email-masked] (Lars Eggert)
Date: Thu Nov 11 16:28:01 2004

--------------ms020806050903030000000309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Pekka,

>   - get things out to get operational experience.

I agree, but I'd like to add that once a WG settles on things, they 
become hard(er) to change at a later time. Temporary solutions have a 
nasty tendency to become permanent. This is why I think we should try to 
be a little more deliberate in our decision-making, even though we 
"only" do experimental things at this time.

...
> What comes to this particular case, I am all for *simplicity* here.

On that, we fully agree, too.

> taken to the DNSEXT working group, and we just can't do that in the HIP WG.

I understood this differently. In my understanding, they were arguing 
that we cannot not force that the DNS contain only a single HIT entry 
per record, i.e., we cannot put constraints on the DNS, it has no 
mechanism to enforce this constraint, and should not. This is obviously 
true.

However, within HIP, we can at this point declare that records with more 
than one HIT per record are *at this time* illegal *for HIP* and we will 
disregard them *for now*. This is *not* a change to the DNS. This is a 
HIP-local decision to interpret the results of DNS records in a specific 
way. Since they're "our" entries, we are free to make this decision.

At a later time, we may *revoke* this restriction, i.e., allow multiple 
hits per FQDN in the DNS, and use whatever HIT-to-IP resolution we then 
have to figure out the set of IP addresses for a specific HIT chosen 
after a DNS lookup.

> That is, if you have multiple HITs associated with the domain name, they 
> must be understood as *equivalent*.  It doesn't matter which one you 
> use.  You can use any.  Hence, if you connect to one of the locators 
> associated with the domain name, you must accept any of the HITs that 
> you got.

Ah, but once we do not use the IP addresses that the DNS returns to 
initiate communiction anymore but maybe use the HITs to look up IP 
addresses in a different resolution mechanism, that is no longer true, 
i.e., you can then expect to reach the host identity that you looked up 
at the IP address you picked.

I'm not sure if I'm explaining this sensibly, and I need to run (meeting 
has ended.) Maybe we can discuss this in person later, else I will write 
something up tomorrow.

> Are we?  I wasn't aware of that.  In which draft?

I thought in hip-dns, but I misinterpreted that one before. Let me 
re-read it carefully.

Lars

--------------ms020806050903030000000309

wxptxOnvAAAAAAAA
--------------ms020806050903030000000309--

---

From: [email-masked] (Pekka Nikander)
Date: Fri Nov 12 06:29:01 2004

Lars,

> mechanism to enforce this constraint, and should not. This is 
> obviously true.

Here we seem to agree.

> However, within HIP, we can at this point declare that records with 
> more than one HIT per record are *at this time* illegal *for HIP* and 
> we will disregard them *for now*. This is *not* a change to the DNS. 
> This is a HIP-local decision to interpret the results of DNS records 
> in a specific way. Since they're "our" entries, we are free to make 
> this decision.

Well, maybe so, but I certainly did not understand it so.  Hence, it is 
certainly good to discuss this at the mailing list, if for nothing else 
to reconfirm.

> i.e., you can then expect to reach the host identity that you looked 
> up at the IP address you picked.

Yes and no.  I agree that then you can expect to find the right IP for 
a given HIT directly.  However, based on Monday's discussion, I still 
get the feeling that from an application point of view you should still 
consider the HITs to denote the same service, and therefore being 
equivalent in that sense.

Considering implementation, I get the feeling that maybe we should go 
for somewhat loose language here, i.e., a number of SHOULD instead of 
MUSTs.  I would suggest the following.  It remains to be determined 
what of this belongs to the DNS draft, what to an appendix in the base 
spec.

   If a host receives multiple HITs in a response to
   a DNS query, those HITs MUST be considered to denote
   a single service, and be semantically equivalent
   from that point of view.  When initiating a base
   exchange with the denoted service, the host SHOULD
   be prepared to accept any of HITs as the peer's
   identity.  A host MAY implement this by using the
   opportunistic mode (destination HIT null in I1), or by
   sending multiple I1s, if needed.

   In particular, if a host receives multiple HITs and
   multiple IP addresses in response to a DNS query, the
   host cannot know how the HITs are reachable at the
   listed IP addresses.  The mapping may be any, i.e.,
   all HITs may be reachable at all of the listed IP
   addresses, some of the HITs may be reachable at some
   of the IP addresses, or there may even be one-to-one
   mapping between the HITs and IP addresses.  In general,
   the host cannot know the mapping and MUST NOT expect
   any particular mapping.

   It is RECOMMENDED that if a host receives multiple HITs,
   the host SHOULD first try to initiate the base exchange
   by using the opportunistic mode.  If the returned HIT
   does not match with any of the expected HITs, the host
   SHOULD retry by sending further I1s, one at time, trying
   out all of the listed HITs.  If the host receives an
   R1 for any of the I1s, the host SHOULD continue to use
   the successful IP address until an R1 with a listed HIT
   is received, or the host has tried all HITs, and try
   the other IP addresses only after that.  A host MAY
   also send multiple I1s in parallel, but sending such
   I1s MUST be rate limited to avoid flooding.

How does that sound?  Any comments?

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Thu Nov 25 03:43:00 2004

Hi Pekka,

More below,

On Friday 12 November 2004 13:40, Pekka Nikander wrote:
> Lars,
>
> > I understood this differently. In my understanding, they were
> > arguing that we cannot not force that the DNS contain only a
> > single HIT entry per record, i.e., we cannot put constraints on
> > the DNS, it has no mechanism to enforce this constraint, and
> > should not. This is obviously true.
>
> Here we seem to agree.
>
> > However, within HIP, we can at this point declare that records
> > with more than one HIT per record are *at this time* illegal *for
> > HIP* and we will disregard them *for now*. This is *not* a change
> > to the DNS. This is a HIP-local decision to interpret the results
> > of DNS records in a specific way. Since they're "our" entries, we
> > are free to make this decision.
>
> Well, maybe so, but I certainly did not understand it so.  Hence,
> it is certainly good to discuss this at the mailing list, if for
> nothing else to reconfirm.

FWIW, I am in favor of storing several HITs and IPs at the same FQDN 
in a flat manner. This allows for easier load balancing, and a couple 
of others features.

<snip>

> Considering implementation, I get the feeling that maybe we should
> go for somewhat loose language here, i.e., a number of SHOULD
> instead of MUSTs.  I would suggest the following.  It remains to be
> determined what of this belongs to the DNS draft, what to an
> appendix in the base spec.
>

This text sounds fine to me. As to the question to what document it 
belongs, it appears to me that these issues are either:

- specific to DNS, in which case the text belongs to the DNS draft.

- impacting any combination of HIP with a 'flat lookup' service (i.e. 
returning a bunch of flats HITs and IPs), in which case the text 
belongs to the base protocol draft, and should be generalized to 
refer to "a flat lookup service (e.g. DNS)" instead of just "DNS".

Comments?

Thanks,

--julien

---

From: [email-masked] (Lars Eggert)
Date: Thu Nov 25 10:04:00 2004

--------------ms090207030000030608010901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

> in a flat manner. This allows for easier load balancing, and a couple 

I've had some time to think on this approach since IETF and am starting 
to like it more than before. I'd still like to see if we give up any 
capabilities by going to this looser mapping between IPs and HITs, but 
this is no showstopper.

Your proposal for the draft (cut to save some trees) is fine, too, both 
the text and the general mechanism.

Lars

--------------ms090207030000030608010901

--------------ms090207030000030608010901--

---

From: [email-masked] (Miika Komu)
Date: Thu Nov 25 16:48:01 2004

> refer to "a flat lookup service (e.g. DNS)" instead of just "DNS".

The text is good. I'd put in the DNS draft because the properties of DNS
are the reason to include this text anyway.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/