Subject: [RAM] dns discover in map-and-encaps schemes

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 07:03:13 -0700

At the RRG meeting on Saturday, there may have been some confusion in
what was meant by DNS discovery in map-and-encaps schemes. For DNS
discovery, only locators are ever kept in the global DNS; identifiers
are *not* kept in the global DNS but rather in a site-specific name
resolution service for the site. From (IPvLX, Section 4):

"4.  DNS Assumptions

   The global DNS [RFC1035] today maintains resource records for Fully
   Qualified Domain Names (FQDNs) with global IPv4 addresses for
   traditional Internet services, and by design anticipates that their
   FQDN-to-address mappings will change relatively infrequently.  IPvLX
   asks only that the global DNS also maintain resource records for
   IPvLX gateways to provide tunnel endpoint addresses - again, under
   the assumption that those FQDN-to-address mappings will change
   infrequently.

   IPvLX further assumes a DNS-like "site-local" name resolution service
   (e.g., [LLMNR]) that is separate from the global DNS and records the
   FQDN-to-IPv6-address mappings for IPv6 application endpoints within a
   site.  Unlike the global DNS, IPvLX assumes that the FQDN-to-IPv6-
   address mappings within the site local name service may change
   dynamically as IPv6 application endpoints come into existence, move
   to new locations and terminate."

This means that a source's address resolution request would trigger
a lookup in the global DNS for the locator(s) associated with the
destination's site, and a lookup for the destination's identifier
in the destination site's name service. The following algorithm is
used:

  1) source does DNS lookup for the FQDN "dest.example.com".
  2) source's DNS server is co-resident on the ingress tunnel router
     and performs a lookup in the global DNS for a well-known prefix
     appended to the FQDN suffix, e.g.: "egress.example.com".
  3) source's DNS server gets back locators for the egress tunnel
     router from the global DNS, then sends an IP-in-IP encapsulated
     RFC4620 Node Information Query asking the egress tunnel router
     to resolve the FQDN "dest.example.com".
  4) egress tunnel router returns identifers associated with
     "dest.example.com"; ingress tunnel router caches the resolution
     and returns the resolution to the source as response to the
     "real" DNS query.

(The above algorithm omits the details of the tunnel setup btw the
ingress and egress tunnel routers, but it should be clear that the
tunnel is set up in parallel with the FQDN resolution.)

Note that (IPvLX, Section 7) currently uses a different mechanism
than RFC4620 because 4630 was not available at the time of the
writing; I'll fix that. Note also that IPvLX fails to reference
RFC1955; I'll fix that too.

Fred
[email-masked]

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2007 17:22:38 -0700

>      and returns the resolution to the source as response to the

What happens when I type "ping <global-address>" on the source? What  
if DNS is down, do I lose global connectivity? What if one of the two  
domain names don't exist in DNS? What if network administrators are  
totally against making routers DNS servers? What if your ITR is a low- 
end router where it can store both the DNS cache and mapping database?

What I am trying to say is, some things need to go into the network  
and some things should just stay out of the network.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2007 17:29:20 -0700

> What happens when I type "ping <global-address>" on the source?  
> What if DNS is down, do I lose global connectivity? What if one of  
> the two domain names don't exist in DNS? What if network  
> administrators are totally against making routers DNS servers? What  
> if your ITR is a low-end router where it can store both the DNS  
> cache and mapping database?

Typo, ... if your ITR is a low-end router where it cannot store ...".

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 01:51:30 -0700

Dino, 

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 5:23 PM
> To: Templin, Fred L
> Cc: rrg; [email-masked]
> Subject: Re: [RAM] dns discover in map-and-encaps schemes
> 

Not quite certain what you mean; do you mean ping the source IP
address from the destination IP address after the source has done
the DNS mapping for the destination. The intent is the egress tunnel
router nearest the destination will have cached the source IP to
locator mapping and so the ping will succeed.

> What if DNS is down, do I lose global connectivity?

What happens if the DNS is down in today's Internet? You can
ping any global IPv4 address and connect to any global IPv4
services by specifying an IP address instead of a FQDN, and
the very same will be true for this scheme. The only thing
you *won't* be able to do is ping IPv6 addresses and connect
to IPv6 services that are deeply embedded in distant sites,
but that is the very same condition as for devices that are
deeply embedded behind NATs in todays Internet. Bottom line
is the situation for loss of global DNS is no different from
and no worse than for the existing condition of today's Internet.

> What if one of the two domain names don't exist in DNS?

The idea is that the global DNS will only ever contain FQDNs
for IPv4-based services; not for any IPv6-based services. So,
there will be only one FQDN in the DNS ("egress.example.com"),
and the FQDN "peer.example.com" will be in the site-specific
name service for the peer's site. The "egress.example.com"
gives the ingress tunnel router unambiguous indication that
the egress tunnel router is participating in the scheme, so
the absense of this FQDN is a clear indication that the peer's
site does *not* implement the scheme. This only means that the
egress tunnel router is responsible for ensuring that its FQDN
is well-maintained in the global DNS. 

> What if network administrators are totally against making routers DNS
> servers?

I want that the function be moved closer to the end devices, and
not in core routers - but, see more below:

> What if your ITR is a low-end router where it can (not) store both the
> DNS cache and mapping database?

The router doesn't need to store the full DNS cache, because the
function it is performing is not exactly that of a full DNS server.
It is really a "two-faced" DNS server that can resolve the FQDNs
for end nodes that are within the same site, but acts as a DNS
resolver for FQDNs for end nodes that reside within different
sites. So, it does not keep a database of global FQDN-to-resource
record mappings - it resolves them from another DNS server just
the same as an ordinary DNS resolver would do.
 
> and some things should just stay out of the network.

I'm all for pushing the function closer to the end devices, and
preferrably on the end devices themselves. That would be consistent
with RFC1955.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 02:52:48 -0700

Dino/Vince/Dave,

Some initial comments on the LISP proposal:

1) The ICMP reply that is triggered by the first packet(s) from the
   ITR to the ETR do not seem to contain any information that could
   help the ITR know that the reply is in fact coming from a
   legitimate on-path ETR. Perhaps add a message digest (MD5 or other)
   to the ICMP reply so that off-path attacker risks can be mitigated?

2) The mechanism is really an open-ended automatic tunneling mechanism.
   This means that it will send encapsulated packets without having any
   way of knowing whether a suitably-configured decapsulator exists on
   the path. Some systems may refuse to accept encapsulated packets if
   they do not have at least a tunnel interface configured a priori,
   and some systems may not configure a tunnel interface by default. I
   *think* we found this to be the case on Linux FC5 (system wouldn't
   accept the packets w/o a tunnel interface configured) but I need
   to go back and verify.

3) Sending encapsulated packets when there is no way of knowing
   whether there is a suitably-configured decapsulator on the path
   could fail to reach some services, e.g., services that reside
   behind NAT boxes and have "holes" punched in the NAT that only
   recognize unencapsulated packets.

4) The spec doesn't say for how long the ITR will continue to send
   encapsulated packets when it gets no replies back from an ETR.
   Will it continue to send the encapsulated packets for the entire
   duration of the flow? If so, this may not work in some cases (see
   above) and will add unnecessary encapsulation overhead in other
   cases. Either way, it seems that legacy systems may suffer before
   the scheme becomes widely deployed.

5) There is also the issue of unnessary IP fragmentation on the path
   when the ITR is not careful about the size of the tunneled packets
   it sends.

Fred

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 20 Mar 2007 11:05:13 +0100

>    to the ICMP reply so that off-path attacker risks can be mitigated?

maybe you want to check

http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-bagnulo- 
lisp-threat-00

regards, marcelo

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 03:28:49 -0700

> locator mapping and so the ping will succeed.

No, it was a simple statement about what if a host uses addresses to  
send packets and not DNS names.

> What happens if the DNS is down in today's Internet? You can

I can still "[ping,traceroute] <global-address>". I can still send  
packets, I can still type in "http://192.168.0.1/" in my browser.

> the very same will be true for this scheme. The only thing

How do you get locators when the DNS is down?

> to IPv6 services that are deeply embedded in distant sites,

A problem.

> not in core routers - but, see more below:

That still won't make network administrators happier.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 03:45:11 -0700

> Some initial comments on the LISP proposal:

Thanks for the comments.

>    ITR to the ETR do not seem to contain any information that could

The Reply goes from the ETR to the ITR.

>    to the ICMP reply so that off-path attacker risks can be mitigated?

Security is going to be addressed in the -01 draft. By using nonces  
and not accepting unsolicited replies solves most of this.

>    way of knowing whether a suitably-configured decapsulator exists on

This depends on how you do the mapping. If the mapping is pushed and  
the ETR registers Locators, then you do know. When you don't know,  
the host sends packet a ICMP protocol unreachable message.

For TE tunnels, you do know because most likely shared-keys will be  
used so there will be a bilateral setup of the tunnel. That means, a  
technical contract between two ISPs.

>    they do not have at least a tunnel interface configured a priori,

This depends on the implementation. I plan to not support it this  
way. LISP does not require the implementation to configure static  
tunnel interfaces in the ITRs and ETRs but strongly recommends it for  
TE-ITRs and TE-ETRs.

>    recognize unencapsulated packets.

Same issue when you don't inject your site based route into BGP.

>    encapsulated packets when it gets no replies back from an ETR.

I will fix that, but intentionally left it out so I can get some  
implementation experience first before choosing a number.

>    the scheme becomes widely deployed.

We will be using routable-IDs globally only for the first phase. We  
plan to have a LISP 3.0 solution soon so we never have routable IDs.  
That is the best direction to pursue.

The ultimate goal should be to address all sites with PI blocks and  
not have those blocks injected into BGP. We really need to get to  
this goal as soon as possible (for both IPv4 and IPv6).

>    when the ITR is not careful about the size of the tunneled packets

Yep, a problem with any tunneling design.

Thanks again. I will get numbers in the spec in about a month or so.

Dino

---

From: Russ White <[email-masked]>
Date: Tue, 20 Mar 2007 08:25:30 -0400

> What happens when I type "ping <global-address>" on the source? What if
> DNS is down, do I lose global connectivity? What if one of the two
> totally against making routers DNS servers? What if your ITR is a
> low-end router where it can store both the DNS cache and mapping database?
> 
> What I am trying to say is, some things need to go into the network and
> some things should just stay out of the network.

Don't these same questions/issues apply to the LISP 1.5/2.0/etc schemes
which follow LISP 1? Perhaps just replacing "DNS server" with something
else?

In fact, won't these questions apply to any real locator/id split
system, in some form or another?

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 05:28:18 -0700

> Sent: Tuesday, March 20, 2007 3:29 AM
> To: Templin, Fred L
> Cc: rrg; [email-masked]

Everything that works today for IPv4 would work tomorrow for IPvLX
for IPvLX nodes that are dual-stacked, which I anticipate would be
the normal case. The only nodes that would not be able to do a ping
to a global address  when the DNS is down would be IPv6-only nodes,
but IMHO those would only occur on very small devices on the very
extreme edges of the network.

> How do you get locators when the DNS is down?

When the DNS is down, you will still be able to use IPv4 in the
same way we use IPv4 in the Internet today. The draft doesn't
explicity say this, but the preferred access method is IPv4,
with IPv6 used only for nodes that do not have a FQDN and IPv4
addresses in the global DNS. IPvLX augments the current
architecture, it does not compromise it.
 
> > to IPv6 services that are deeply embedded in distant sites,

See above; the situation is no different than for the Internet
today. Again, IPvLX augments the existing architecture; it does
not compromise it.
 
> That still won't make network administrators happier.

Howso? Why should the network administrator care if the end
node is simply behaving as an ordinary DNS resolver from an
outward appearance. That the end node is behaving as a
two-faced DNS server on behalf of its downstream-attached
devices (and internal virtual hosts) is no business of the
network administrator's.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 05:41:32 -0700

> Sent: Tuesday, March 20, 2007 3:45 AM
> To: Templin, Fred L
> Cc: [email-masked]; rrg
> Subject: Re: [RRG] Initial comments on the LISP proposal
> 

Correct; I had a dyslexic moment.
 
> and not accepting unsolicited replies solves most of this.

I defer to the threat analysis document and the -01 draft.
 
> >    This means that it will send encapsulated packets 
> without having  
> > any

But if you don't get the ICMPs, it appears as a black hole.

> technical contract between two ISPs.

No problem for configured tunnels, obviously.
 
> tunnel interfaces in the ITRs and ETRs but strongly 

I'm not concerned about the LISP-enlightened nodes; I'm concerned
for the legacy nodes that don't yet implement the scheme and I
believe you may be in for some backward-compatibility issues.
 
> Same issue when you don't inject your site based route into BGP.

I don't understand your response; I was saying that the encapsulated
packets are delivered to the NAT box in front of the server, but the
NAT has a hole punched through it that only recognizes unencapsulated
packets. The service will therefore be unreachable.

> implementation experience first before choosing a number.

OK, I'll watch for it.

> That is the best direction to pursue.

I'll watch for that too.

> this goal as soon as possible (for both IPv4 and IPv6).

I'll agree with that.

> Yep, a problem with any tunneling design.

Fixable with a suitable tunnel path MTU assurance mechanism.
 
> Thanks again. I will get numbers in the spec in about a month or so.

OK - Fred

---

From: Russ White <[email-masked]>
Date: Tue, 20 Mar 2007 08:43:59 -0400

To wit: In a slightly later email:

> We will be using routable-IDs globally only for the first phase. 
> We plan to have a LISP 3.0 solution soon so we never have routable IDs. 

What happens if I "ping <id>," and the LISP server is down?

I'm not saying we shouldn't consider a case where nothing happens, I'm
simply saying this brings up a fundamental point we need to consider in
all cases of locator/id split, including LISP 3.0.

Is it okay for the network to fail when some set of network reachable
servers, or some network accessible service, fails? If it is, then any
number of schemes will work for a locator/id split, and we should
consider the end result of any system, rather than using one step here,
and another step there.

Perhaps it's best to:

1. Consider the problem of reachability being predicated on a service.
This is a fundamental change in architecture, and we should consider it
as a correlation, one of the possible negative side effects, of a
locator/id split of any type.

2. Consider the end result of any given system. Right now, we're seeing
a lot of things thrown out, where someone says: "In version 1, we do
this, in version 2, we do that, in version 3, we do the other thing."
This is very confusing, and makes for a lot of shifting
conversation--more heat than light, in many cases. Start from where you
want to be, and let's consider the final end point. If that looks good,
then let's figure out what the transition mechanisms are.

I think we might be working the wrong way around, looking at proposals
to solve a problem, and not considering the tradeoffs and possible
problems we're going to be creating. Further, we're looking at systems
that have several stages, and sometimes comparing stage 1 of system x
against stage 2 of system y, which is then countered by comparing stage
1 of system y against stage 2 of system y.

Let's stick to final results, so everything is compared on a level
playing field.

Just a thought.

:-)

Russ

- --

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 20 Mar 2007 06:29:31 -0700

this is not a reply to your msg but a question of where you'd like to  
direct the discussion to: I am very sure I'm not the only on both  
lists and found double-copies on every msg confusing (given how far  
I'm behind, this does not help)

I strongly discourage any future posts going to both ram and rrg,  
given the potential high overlap in membership between the two. One  
can easily send a note to list 1 telling others that he has posted an  
important thing to list 2.

Fred you started this double-list posting, which list would you like  
to continue on?
Personally it seems to me mostly belonging to RAM, though you may  
feel otherwise.

On Mar 20, 2007, at 5:28 AM, Templin, Fred L wrote:

> --
> to unsubscribe send a message to [email-masked] with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 07:33:48 -0700

Hi Lixia, and thanks for the guidance on this. I certainly agree
with minimizing the clutter, and am happy to move to just one list.
I don't have a preference as to which one, so I defer to your
judgement and will use just one list from now on.

But, a procedural question: how can we decide which is the
appropriate list on a case-per-case basis? (I think we still
have all three of the ram, rrg, and architecture-discuss lists
to choose from?)

Thanks - Fred

> From: Lixia Zhang [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 6:30 AM
> To: Templin, Fred L
> Cc: Dino Farinacci; rrg; [email-masked]
> Subject: Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 07:34:18 -0700

>> What if

Exactly why I asked the questions.

> system, in some form or another?

Yep.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 07:33:48 -0700

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 07:34:18 -0700

Yep.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 08:23:34 -0700

> architecture, it does not compromise it.

You told me why it would work. I want to know how. You didn't answer  
my question. So if a host sends a DNS query to the router (you have  
said the router is a DNS server), and the router then needs to  
resolve egress.example.com and can't, please tell me what happens.

You can't say just like IPv4 today because this doesn't happen in  
IPv4 today.

> outward appearance. That the end node is behaving as a

I didn't say they cared about that. They want to manage DNS servers  
in what has been traditionally known as "host systems", like one  
running FreeBSD, Linux, or Windows Server.

> devices (and internal virtual hosts) is no business of the

Right, give me a break. The network administrator manages this stuff  
and is responsible for making it work and keeping it working.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 08:31:03 -0700

> believe you may be in for some backward-compatibility issues.

The legacy nodes don't are not LISP boxes and don't have to change.  
To them the packets between the ITR and ETR are just plain old IPv4  
or IPv6 packets.

> packets. The service will therefore be unreachable.

NAT breaks a lot of things. The ETR has to be upstream of the NAT or  
collocated in the NAT.

> Fixable with a suitable tunnel path MTU assurance mechanism.

Yes, you can do PMTU with encapsulated data packets from ITR to ETR.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 09:01:46 -0700

Hi Dino,

(Taking Lixia's guidance and reducing down to one list): 

> Sent: Tuesday, March 20, 2007 8:24 AM
> To: Templin, Fred L
> Cc: rrg; [email-masked]

OK, so going with what I said earlier about IPv4 being the preferred
service, what I would like to see happen is for the router to first
try to resolve "dest.example.com". If that resolves to a set of A
records, then the router can simply return them to the end system
and the application can use IPv4 - great! But, if there are no
resource records for "dest.example.com", the router would then
resolve "egress.example.com" and get back a set of A records for
that. Then, it would send the Node Information Query for
"dest.example.com" to one of those IPv4 addresses and get a set
of AAAA records back.

But, a nice optimization would be if the router could resolve
"dest.example.com" and "egress.example.com" *both at the same time*
and then act according to the algorithm above based on what it gets
back. Maybe you know - is it possible to "batch" multiple queries
in a single DNS transaction?

As to failure to resolve either domain name, why would it be any
different than for the same thing in today's Internet? The end
system tries to resolve a FQDN and gets no resource records back.
Maybe you are concerned that the router would appear to be "alive"
from the end system's perspective while the global DNS service was
"dead". In that case, why can't the server process on the router
simply "play dead"?

> and is responsible for making it work and keeping it working.

Hmm; I hear about end systems implementing personal firewalls
these days. If they do that, then why can't they also implement
personal DNS servers?

Fred

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 20 Mar 2007 10:19:38 -0700

> have all three of the ram, rrg, and architecture-discuss lists

let me try a paraphrase of Leslie's answer when this question was  
raised at RRG meeting last Saturday (I copied Leslie here in case I  
say it wrong):

RRG list should be used for messages related to RRG's efforts
   in developing a scalable routing&addressing architecture.
RAM list should be used for messages related to Internet routing and
   addressing that are out of RRG scope.
arch-d list should be used for all other architecture related issues.

Lixia