Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)
draft-ietf-lisp-alt-10

[Ballot discuss]
#1 cleared

I'm just gonna keep #2 until I go re-read [LISP-MS] now that
I've done the base and ALT (all of which really seem needed to get
the others;-)

#2 [LISP] has an authentication header for Map-Register and
Map-Notify messages.  I thought I'd see text here about how to set
that up. But I didn't see it. Shouldn't this document say something
about that? If not, then which one does? (Maybe its back in
[LISP-MS]?)

[Ballot discuss]
#1 cleared

I'm just gonna keep #2 until I go re-read [LISP-MS] now that
I've done the base and ALT (all of which really seem needed to get
the others;-)

#2 [LISP] has an authentication header for Map-Register and
Map-Notify messages.  I thought I'd see text here about how to set
that up. But I didn't see it. Shouldn't this document say something
about that? If not, then which one does? (Maybe its back in
[LISP-MS]?)

[Ballot comment]
Thank you for addressing my Discuss.
One of my Comments remains in the latest version, but it is not blocking...

---

Abstract

I can't parse...

  Termed the Alternative Logical
  Topology (ALT), the index is built as an overlay network on the
  public Internet using the Border Gateway Protocol (BGP) and the
  Generic Routing Encapsulation (GRE).

The "index" is termed the ALT?
The "index" is built as a network?

Maybe s/index/distributed index system/ ?

[Ballot comment]
I picked out the same sentence as several others...

  EID-prefixes are expected to be allocated to a LISP site by Internet
  Registries.

...but I wondered whether you were saying something less alarming than they interpretted (for example, that the addresses are not from a private space). In any case, clarification will surely help.

---

Abstract

I can't parse...

  Termed the Alternative Logical
  Topology (ALT), the index is built as an overlay network on the
  public Internet using the Border Gateway Protocol (BGP) and the
  Generic Routing Encapsulation (GRE).

The "index" is termed the ALT?
The "index" is built as a network?

Maybe s/index/distributed index system/ ?

[Ballot discuss]
Apologies if these discuss points aren't as well thought out as they
should be - I ran out of time basically;-)

#1 Could a bad xTR use the ALT DB in order to find information that
it then uses to cause some site's EIDs to be associated with the bad
xTR? E.g. bad-guy wants to get good-guy's traffic. Bad-guy asks the
ALT for RLOCs for good-guy and then creates Map-Replies that it
(bad-guy) sends to a target. I guess the real question is if I know
all the good-guy's EIDs and RLOCs can I use that to convince the
target to add one more RLOC (at bad-guy) to the list for good-guy?

#2 [LISP] has an authentication header for Map-Register and
Map-Notify messages.  I thought I'd see text here about how to set
that up. But I didn't see it. Shouldn't this document say something
about that? If not, then which one does? (Maybe its back in
[LISP-MS]?)

[Ballot comment]
#1) s10.2: In the following, I think you're talking about the HMAC in TCP not BGP so in the following:

  Use of HMAC Protected BGP/TCP Connections:  HMAC is used to verify
    message integrity and authenticity, making it nearly impossible
    for third party devices to either insert or modify messages.

r/HMAC Protected BGP/TCP Connections/HMAC-Protected TCP Connections for BGP peers
r/HMAC/HMAC (e.g., TCP-AO [RFC5925]) and maybe an informative reference to RFC 5925?

#2) s10.3: I tend to agree with Adrian on the references to S-BGP and soBGP.  The IETF has decided to work on BGP security in SIDR lets point there and not muddy the waters with references to long expired draft.

[Ballot discuss]
#1) s10.1: So the answer to the following question:

  Mapping Integrity:  Can an attacker insert bogus mappings to black-
    hole (create Denial-of-Service, or DoS attack) or intercept LISP
    data-plane packets?

is ...?  Maybe just rephrase this a statement?  Just looking for truth in advertising.

[Ballot comment]
=====
  Using these proven protocols,
  the ALT can be built and deployed relatively quickly without any
  changes to the existing routing infrastructure.

SB> Whilst this may be true the text sounds like it fell off the
SB> back of a marketing slide.

=====

    Legacy Internet:  The portion of the Internet which does not run
      LISP and does not participate in LISP+ALT.

SB> A rather pejorative term. Particularly as LISP is an
SB> experimental protocol.

=========

3.3.  Caveats on the use of Data Probes

  It is worth noting that there has been a great deal of discussion and
  controversy about whether Data Probes are a good idea.  On the one
  hand, using them offers a method of avoiding the "first packet drop"
  problem when an ITR does not have a mapping for a particular EID-
  prefix.  On the other hand, forwarding data packets on the ALT would
  require that it either be engineered to support relatively high
  traffic rates, which is not generally feasible for a tunneled
  network, or that it be carefully designed to aggressively rate-limit
  traffic to avoid congestion or DoS attacks.  There may also be issues
  caused by different latency or other performance characteristics
  between the ALT path taken by an initial Data Probe and the
  "Internet" path taken by subsequent packets on the same flow once a
  mapping is in place on an ITR.  For these reasons, the use of Data
  Probes is not recommended at this time; they should only be
  originated an ITR when explicitly configured to do so and such
  configuration should only be enabled when performing experiments
  intended to test the viability of using Data Probes.


SB> This text looks like it needs to be in the main LISP spec.
SB> There also needs to be text discussion the impact of the
SB> cache system on connectionless flows.

========

SB> There does not seem to be a definition of "PI"

[Ballot comment]
I picked out the same sentence as several others...

  EID-prefixes are expected to be allocated to a LISP site by Internet
  Registries.

...but I wondered whether you were saying something less alarming than they interpretted (for example, that the addresses are not from a private space). In any case, clarification will surely help.

[Ballot discuss]
I think it is not right to make references (even Informative) to two I-Ds that have very clearly expired and gone away.

Both [I-D.murphy-bgp-secr] and [I-D.white-sobgparchitecture] are substantially retired and are clearly not "work in progress". I suggest you look at work done in KARP and SIDR for starting points in the discussion of BGP security developments. You might also look at TCP/AO.

[Ballot discuss]
You say, "EID-prefixes are expected to be allocated to a LISP site by Internet Registries." For IPv4, this may be a non-starter.

This viability of ALT, like the base document, depends on the viability of the Interworking document that we have not seen yet.

[Ballot comment]
What does this phrase from the definition of EID-prefix mean:

      EID-
      prefixes are routed on the ALT (not on the global Internet)

Perhaps "information about EID-prefixes is exchanged among ALT
routers through BGP" or "Map-Requests are routed through the ALT to
the ETR that owns the requested EID-prefix"?

From section 4:

  An ITR uses the ALT to learn the best path for forwarding an ALT
  Datagram destined to a particular EID-prefix.

Really?  Does the ITR really learn the best path?  I thought the
forwarding was all done transparently by the ALT routers.

In section 6.1, I think LISP+ALT MUST "use newly-assigned AS numbers
that are unrelated to the ASNs used by the global routing system."
Presumably the lisp WG or some appropriate authority on behalf of the
experiment will formally request the ASNs from IANA?

From section 7:

  The ALT BGP peering topology should be arranged in a tree-like
  fashion (with some meshiness), with redundancy to deal with node and
  link failures.

I would need some additional detail if I were to participate in the
experiment.  I thought the ALT routers formed a mesh of sorts.
Does "tree-like fashion (with some meshiness)" mean a tree topology
within a LISP site and a mesh among sites?

[Ballot discuss]
This Discuss is related to my Discuss on draft-ietf-lisp.  From
section 4.2:

  EID-prefixes are expected to be allocated to a LISP site by Internet
  Registries.

Wow.  That expectation makes for some experiment!  Shouldn't this
expectation be highlighted somewhere in draft-ietf-lisp?  What are the
requirements for these allocations, both relative to other allocations
of EID-prefixes and allocations of IP address space?

[Ballot discuss]
This document is essentially ready for publication as Experimental, but I would like to ask about the status of one 10-year expired informational reference (I-D.murphy-bgp-secr). Are there plans to update and eventually publish this draft? If not, is there something more recent that could be used instead?

(Sorry, hit the send button too soon) -

Also, what are the plans for [I-D.white-sobgparchitecture]?

[Ballot discuss]
This document is essentially ready for publication as Experimental, but I would like to ask about the status of one 10-year expired informational reference (I-D.murphy-bgp-secr). Are there plans to update and eventually publish this draft? If not, is there something more recent that could be used instead?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (LISP Alternative Topology (LISP+ALT)) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP Alternative Topology (LISP+ALT)'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a simple distributed index system to be used
  by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
  (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
  which holds the mapping information for a particular Endpoint
  Identifier (EID).  The MR can then query that ETR to obtain the
  actual mapping information, which consists of a list of Routing
  Locators (RLOCs) for the EID.  Termed the Alternative Logical
  Topology (ALT), the index is built as an overlay network on the
  public Internet using the Border Gateway Protocol (BGP) and the
  Generic Routing Encapsulation (GRE).  Using these proven protocols,
  the ALT can be built and deployed relatively quickly without any
  changes to the existing routing infrastructure.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp-alt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp-alt/


No IPR declarations have been submitted directly on this I-D.

Vince,

>> I'm looking at the Map-Request message format and cannot quite convince
>> myself that there would never be a situation where MTU would be exceeded.
>> 99.999% of the time it would be fine, but I think we need to describe (if
>> not fix) what happens when its not. How about adding the following item to
>> the Section 1 experimental list:
> I don't really understand how MTU could be an issue here. If there is an
> MTU restriction, fragmentation would occur upon entry into an ALT GRE
> tunnel and reassembly would be done when the ALT datagram is received by
> an ETR.

OK.

(Maybe this should be said somewhere in the draft. Or maybe it already is and I just missed it...)

>> "o  effects of limited possibilities for returning an ICMP message from ALT"
> It is certainly possible for an intermediate ALT router to be unable to
> forward an ALT Datagram for some other reason, such as there being no
> matching next hop (i.e. the destination is not an EID and therefore is not
> reachable via the ALT).

OK. Lets focus on the general issue, not the specific MTU problem.

> In such cases, the ALT router which cannot forward
> the datagram would drop it. Section 4.2 describes what an ETR can do if
> it receives an ALT datagram destined for a non-EID: it returns a negative
> Map-Reply. An ALT router that understands LISP (i.e. a Map Server or Map
> Resolver connected to ALT) could similarly send a negative Map-Reply if
> it cannot forward a Map-Request over the ALT.

Yes, and this is good. But FWIW -- and maybe this is one reason why the issue has been unclear to me -- Section 4.2 seemed to talk about this only in the context of aggregate prefixes and their holes. And it does talk about only ETRs, not ALT routers. Would it be possible to add something from your above description to the text?

> An ALT router could attempt to return an ICMP message to the RLOC source
> in a Map-Request received over the ALT. Whether that ICMP message would
> be received by the Map-Request source (ITR) would depend on whether the
> ALT router has legacy Internet connectivity in addition to being on the
> ALT virtual network. The current Cisco LISP implementations do not attempt
> to return ICMP messages when a failure occurs forwarding on the ALT VRF.
>
> If an ITR were to send a Map-Request into the ALT that cannot be delivered
> over the ALT due to some IP-layer problem, it may very well not receive
> any positive failure indication. Since such a scenario could only arise
> through misconfiguration or another serious problem on the ALT network,
> having an ITR treat the destination as non-LISP-reachable is, in my opinion,
> the right thing to do, so I don't see a need for additional machinery.

This may well be so. And I agree that additional machinery might not be helpful.

>> and this text somewhere:
>>
>> "Given that packets delivered through ALT have an RLOC source address and
>> an EID destination address, returning an ICMP error may not always be
>> possible. Since Map-Request messages are typically small, it is unlikely
>> that an MTU violation will occur for a Map-Request forwarded on the ALT and
>> if it did, it may be possible to deal with it through fragmentation of GRE
>> packets. But in the unlikely event of having to generate an ICMP error due
>> to MTU or other problems, an ALT node MAY attempt to deliver the error to
>> the source RLOC outside ALT. If it turns out to be not possible to deliver
>> the ICMP error, the sender of the Map-Request message will retry, and
>> failing again, will time out.This could lead to considering the dstination
>> not LISP-capable. Note that ICMP errors are more likely with Data Probes,
>> and may lead to the unreported loss of the encapsulated data packet."
> If you feel it is important enough, we can certainly add text of this sort
> stating that an ALT router may attempt to return an ICMP message if it cannot
> forward an ALT Datagram. None of the authors think that this is really
> necessary.

I think I understand the situation now better, thanks for the explanation. I don't think we need to specify a way to send ICMP messages, but I still think it would be reasonable to explain the situation to the reader. Here's a second try for new text:

"Given that packets delivered through ALT have an RLOC source address and an EID destination address, returning an ICMP error may not be possible. As described in Section 4.2., the reception of a packet that has no destination in ALT can be treated by ETRs or even the ALT routers by sending a negative Map-Reply. It is expected that MTU problems are handled as a part of GRE tunnels. Other problems can only occur through misconfiguration or other serious problems with the ALT network. The ALT design treats the remaining cases as packet loss. The sender of a Map-Request may retry sending a message, and failing again, will eventually time out. This leads to treating the destination as not reachable through LISP, which is is the the best or only course of action that can be performed under such circumstances."

Comments? Feel free to propose your own text. But I'd like to have something in the draft about this, and this is the only thing preventing the draft going to Last Call...

Jari

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
Vince, Dino,

I wrote:

> I'd still like to understand the ICMP message situation better. I realize
> that the traffic is supposed to be unidirectional, but how would, say,
> lower MTU somewhere along the path be dealt with? I'm not necessarily
> asking for a change in what the spec does, but it should be clear about the
> consequences.

Vince wrote:

> Under normal circumstances, the only thing that should be send across the
> ALT would be a Map Request, which should not cause MTU problems. Of course,
> if a (deprecated) Data Probe were used, then all bets are off.
>
> If a Map Request or Data Probe were to hit an MTU problem or otherwise be
> undeliverable across the ALT and no ICMP message could be returned from the
> ALT node where the failure occurred to the Map Request originator, then
> the originator would retry sending the Map Request several times before
> timing-out. If such a timeout occurred, then the destination would be
> considered not LISP-capable and LISP encapsulation would not be done
> toward it.

Dino wrote:

> Since Map-Requets are small, it is unlikely that an MTU violation will occur for a Map-Request forwarded on the ALT. But if the case did arise, there would be fragmentation and reassembly at each GRE end-point since a Map-Request, when sent from one ALT node to another, is encapsulated in a GRE tunnel header.

I'm looking at the Map-Request message format and cannot quite convince myself that there would never be a situation where MTU would be exceeded. 99.999% of the time it would be fine, but I think we need to describe (if not fix) what happens when its not. How about adding the following item to the Section 1 experimental list:

"o  effects of limited possibilities for returning an ICMP message from ALT"

and this text somewhere:

"Given that packets delivered through ALT have an RLOC source address and an EID destination address, returning an ICMP error may not always be possible. Since Map-Request messages are typically small, it is unlikely that an MTU violation will occur for a Map-Request forwarded on the ALT and if it did, it may be possible to deal with it through fragmentation of GRE packets. But in the unlikely event of having to generate an ICMP error due to MTU or other problems, an ALT node MAY attempt to deliver the error to the source RLOC outside ALT. If it turns out to be not possible to deliver the ICMP error, the sender of the Map-Request message will retry, and failing again, will time out.This could lead to considering the dstination not LISP-capable. Note that ICMP errors are more likely with Data Probes, and may lead to the unreported loss of the encapsulated data packet."

Or something along those lines.

Jari

I have reviewed this draft. Like the other drafts that I have read, it was well written and pleasure to read. Thanks for doing good work.

This draft does have some hand waving in some aspects (like exactly how the ALT is built), but that's acceptable for an experimental specification. I did have four remaining issues that I would like to talk about though. One is a question and for the other three I have some suggested way forward. I also have a small set of editorial suggestions at the end of this mail. Please respond and/or revise draft so that we can send this one to IETF Last Call.

Technical:

The question is about the treatment of RLOC source and EID destination addresses when something bad happens in ALT (no route or some other problem, say MTU limitation). Do you expect ICMP messages be sent back, and if so, how?

The use of RLOC source addresses seems to have an effect on intermixing IPv4 and IPv6 addresses. It would perhaps be desirable in some cases to allow IPv4 RLOCs while working with IPv6 EIDs, for instance. But those RLOCs cannot be directly used on IPv6 packets that carry IPv6 destination addresses. (At least not without agreeing that some form of mapped addresses are used. But that doesn't work for carrying an IPv6 source address in an IPv4 packet.) My suggestion is to add some text about this.

As this is an experimental specification and because we do not fully understand all aspects of its operation, I think it is useful to add some description at the beginning about the areas where further experience is needed.

Finally, I'm concerned about the Section 6.1 recommendation to use a "new numbering space that is unrelated to the ASNs used in the global routing system". First of all, its not clear to me what you are saying here. Are you (a) recommending that the 32-bit ASN space can just be reused and it doesn't matter if ALT uses the same numbers as someone in the current Internet? Or are you saying (b) that some new allocations (or perhaps even a small subspace) should be allocated from the existing ASN space and used for ALT, without colliding with any existing allocations? I think the former would be problematic, because its hard to prevent accidental leakage. But getting some new numbers for ALT usage would perfectly fine, IMO. I'm also wondering if we should just allocate a new SAFI (even if we do not require that legacy router implementations use it).

Here's some suggested text changes for Section 6.1:

OLD:
  To avoid confusion, it needs to be stressed that that
  these LISP+ALT ASNs use a new numbering space that is unrelated to
  the ASNs used by the global routing system.
NEW:
  To avoid confusion, it needs to be stressed that that
  these LISP+ALT ASNs should use newly allocated ASN numbers that are unrelated to
  the ASNs used by the global routing system.

And some suggested new text for Section 1, to be inserted just before the last paragraph:

NEW:
  This specification is experimental, and there are areas where further experience is needed
  in order to understand the best implementation strategies, operational models, and impacts to
  the rest of the Internet. These areas include:

  - application effects of on-demand route map discovery
  - the impacts of using map requests versus carrying initial packets in ALT
  - the best practical ways to build ALT hierarchies
  - effects of route leakage from ALT to the current Internet
  - effects of exceptional situations, such as denial-of-service attacks

  Experimentation, measurements, and deployment experience on these aspects is
  appreciated. While the theoretical impacts are often understood (such as an ALT
  lookup causing a potential delay for the first packet destined to a given network),
  it is less clear what effects, if any, these may have with real world traffic patterns.

  ALT cannot support mixed use of IPv4 and IPv6 addresses, as it requires the use of the same
  address family for both RLOCs and EIDs.

(Feel free to suggest alternate text.)

Editorial:


> ... little, if any, LISP-specific modifications should be
> needed for such devices to be deployed on the ALT.

Perhaps you could add a reference to Section 4.2 that discusses what is possible and is not possible with pure off-the-shelf routers. Otherwise the statement feels a little bit fuzzy.

s/on the ALT./on the ALT (see Section 4.2)./

>  == Outdated reference: A later version (-15) exists of draft-ietf-lisp-14
>
>  == Outdated reference: A later version (-11) exists of draft-ietf-lisp-ms-09
>

(from idnits, please fix)

>    Endpoint ID (EID):  A 32-bit (for IPv4) or 128-bit (for ipv6) value
>    reachability is carried as IPv4 or ipv6 NLRI without modification
>


s/ipv6/IPv6/

> This might be done minimize packet loss and to
>      probe for the mapping.

... might be done to minimize ...

>    low performance expected of a tuneled topology, ALT Routers (and Map
>

s/tuneled/tunneled/

Jari

(1.a) Terry Manderson is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document has had adequate review. The shepherd has no concerns
regarding the reviews which have been performed.

(1.c) The document shepherd does not have concerns that the document
requires a broader review.

(1.d) The document shepherd has no specific concerns, No IPR disclosures
have been raised.

(1.e) The WG consensus reflects active agreement among about about 10
participants, with the bulk of the WG being silent, and a few
vocal objectors.

(1.f) No threats of appeal or discontent on this document have
manifested.

(1.g) IDNITs responds with:


== There are 5 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be
changed
to use any of the ranges defined in RFC 5735 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.


The authors responded with the need to call on a broader and deeper set
of example prefixes to add meaning to the document. Documentation prefixes
alone could not provide this so RFC1918 based addresses were used.


(1.h) References have been split. No downward normative references exist.

(1.i) The document makes no request of the IANA

(1.j) Formal language has been verified.

(1.k)
Technical Summary

This document describes a simple distributed index system to be used
by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
which holds the mapping information for a particular Endpoint
Identifier (EID). The MR can then query that ETR to obtain the
actual mapping information, which consists of a list of Routing
Locators (RLOCs) for the EID. Termed the Alternative Logical
Topology (ALT), the index is built as an overlay network on the
public Internet using the Border Gateway Protocol (BGP) and the
Generic Routing Encapsulation (GRE). Using these proven protocols,
the ALT can be built and deployed relatively quickly without any
changes to the existing routing infrastructure.

Working Group Summary

Many of the comments received during last call were complex and
difficult for the working group to understand. The working group last
call was held open for an extended time to ensure sufficient discussion
and sufficient effort to address those objections.

Document Quality

Several (3+) LISP implementations exist using the ALT topology.