Subject: [lisp] AD review of draft-ietf-lisp (part 2)

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Oct 2011 01:02:02 +0300

Continuing with my review. Many of the observations below are questions. I may understand most of these better once I finish the whole document, but I wanted to send out my notes already now.

Technical:

>     o  End-systems (hosts) only send to addresses which are EIDs.  They
>        don't know addresses are EIDs versus RLOCs but assume packets get
>        to LISP routers, which in turn, deliver packets to the destination
>        the end-system has specified.
>

Is this always true, e.g, when some interworking mechanism between the LISP and non-LISP parts of the Internet is in use, and one of the peers employs some NAT traversal techniques? It would seem that there can be cases where the peers observe RLOC addresses and use them for some purpose.

This might be something to mention in the limitations/things to test section, for instance, or discussed in in the interworking document (and maybe it already is, I did not check).

>
>  A server host can be the endpoint
>       of a LISP tunnel as well.
...
>     o  RLOCs are always IP addresses assigned to routers
>

Isn't this an inconsistency? Or is a server that terminates a tunnel called a router?

>     o  When a router originates packets it may use as a source address
>        either an EID or RLOC.

You should state somewhere what the manageability requirements are for making this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use of addresses). Does this require additional functionality for RFC 3484 style source address selection, or can you cope with existing functionality?

Note: I'm not asking for any new functionality, just a statement about the expectations.

>     In order to avoid excessive packet overhead as well as possible
>     encapsulation loops, this document mandates that a maximum of two
>     LISP headers can be prepended to a packet.

This seems hard to mandate in any real sense. Perhaps you want to say "recommends" instead of "mandates"?
>     2.  The LISP ITR must be able to map the EID destination to an RLOC
>         of one of the ETRs at the destination site.  The specific method
>         used to do this is not described in this example.  See [ALT  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-ALT>] or
>         [CONS  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-CONS>] for possible solutions.
>
>     3.  The ITR will send a LISP Map-Request.  Map-Requests SHOULD be
>         rate-limited.
>
>     4.  When an alternate mapping system is not in use, the Map-Request
>         packet is routed through the underlying routing system.
>         Otherwise, the Map-Request packet is routed on an alternate
>         logical topology.  In either case, when the Map-Request arrives
>         at one of the ETRs at the destination site, it will process the
>         packet as a control message.

First, the the "alternate mapping system" appears here for the first time. Maybe you should indicate it refers to [ALT].

Second, parts of step 4 go pretty deep in what the specific mapping methods are. I'm wondering if this alternative text would fit better:

"4.  The Map-Request packet is delivered to the right ETR with the help of the mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing topology.) In any case, when the Map-Request arrives ..."

> 6.  The ITR receives the Map-Reply message, parses the message (to
>      check for format validity) and stores the mapping information
>      from the packet.  This information is stored in the ITR's EID-to-
>      RLOC mapping cache.  Note that the map cache is an on-demand
>      cache.  An ITR will manage its map cache in such a way that
>      optimizes for its resource constraints.
>

This is just a comment, but FWIW, I am not super happy about the way the caching is an integral part of the specifications for LISP. Fundamentally, you could have used two orthogonal tools for dealing with routing scalability: 1. have only a subset of routers have to deal with EID routing (the xTRs) and 2. use caching for scaling these routers better. If we had done this, then we would have had a very easy answer to those who have criticized the caching approach over the years: it is optional and up to the implementors to use or not. The first tool would still have been a valid approach to make the Internet scale better, even if you never did any caching.

In any case, your description of the thins-to-test should probably say something about effects of caching.

>     8.  The ETR receives these packets directly (since the destination
>         address is one of its assigned IP addresses), strips the LISP
>         header and forwards the packets to the attached destination host.
>
>    Spoofing of inner header addresses of LISP encapsulated packets is
>    possible like with any tunneling mechanism.  ITRs MUST verify the
>    source address of a packet to be an EID that belongs to the site's
>    EID-prefix range prior to encapsulation.  An ETR must only
>    decapsulate and forward datagrams with an inner header destination
>    that matches one of its EID-prefix ranges.  If, upon receipt and
>    decapsulation, the destination EID of a datagram does not match one
>    of the ETR's configured EID-prefixes, the ETR MUST drop the
>    datragram.  If a LISP encapsulated packet arrives at an ETR, it MAY
>    compare the inner header source EID address and the outer header
>    source RLOC address with the mapping that exists in the mapping
>    database.  Then when spoofing attacks occur, the outer header source
>    RLOC address can be used to trace back the attack to the source site,
>    using existing operational tools.

First, I think Step 8 should be slightly edited to cover the fact that some additional checks are being made. E.g., "The ETR receives these packets directly (since ...), checks the validity of the addresses used in the packet, strips the LISP header and ..."

Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to  source RLOC?

> The next sub-sections illustrate packet formats for the
>     homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
>     combinations SHOULD be supported.

For interoperability, wouldn't it be cleaner to have a MUST here? How would I otherwise know if I can send an IPv4-in-IPv6 packet to a destination?

Editorial:

> Since additional tunnel headers are prepended, the packet becomes
> larger and can exceed the MTU of any link traversed from the ITR to
> the ETR.  It is recommended in IPv4 that packets do not get
> fragmented as they are encapsulated by the ITR.  Instead, the packet
> is dropped and an ICMP Too Big message is returned to the source.
>

This feels odd, as there is no explanation in this point about what you do with IPv6. Maybe a sentence on IPv6 should be added?

I'm sure the details on IPv6 follow later in the document, but I suspect that other readers would be wondering here in the same way as I am.

I'm reading on...

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 3 Oct 2011 15:46:37 -0700

> Continuing with my review. Many of the observations below are questions. I may understand most of these better once I finish the whole document, but I wanted to send out my notes already now.

Thanks for getting something out sooner rather than latter. See my comments inline. 

> Is this always true, e.g, when some interworking mechanism between the LISP and non-LISP parts of the Internet is in use, and one of the peers employs some NAT traversal techniques? It would seem t…

But they don't know they are RLOC addresses. All end-systems assume is that addresses they put int destination address fields will make it to the destination. So if the address is an RLOC, the underlying routing system will have routes to get the packet to the destination. Otherwise, the packet moves toward a LISP router that will encapsulate to get the packet to the destination.

> This might be something to mention in the limitations/things to test section, for instance, or discussed in in the interworking document (and maybe it already is, I did not check).

We mentionn nothing because the host doesn't care and doesn't need to care.

> Isn't this an inconsistency? Or is a server that terminates a tunnel called a router?

For the sake of this document and keeping it within the charter of the working group, a router is a LISP router. We do not consider hosts doing LISP as specified in the LISP-MN document. Which is out of charter for this working group.

So if a server is acting as a router, then it has RLOCs. 

Hosts have EIDs assigned to them (when they are resident in a LISP site), IGP routers have EIDs assigned to them, and LISP routers have both EIDs and RLOCs assigned to them.

> You should state somewhere what the manageability requirements are for making this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use of addresses). Does this require addition…

It does not. The same requirements for originating IP packets has not changed. If it is stated that the outgoing interface's address is used as the source address, then whatever namespace the address belongs to is used.

> Note: I'm not asking for any new functionality, just a statement about the expectations.

No expectations.  ;-)

> This seems hard to mandate in any real sense. Perhaps you want to say "recommends" instead of "mandates"?

We thought long and hard about this and wanted to mandate to indicate the seriousness of not going overboard with encapsulation. Now I know implementors can ignore specs, but for the record when it is documented the way we did it is more clear on the strength of the statement.

> First, the the "alternate mapping system" appears here for the first time. Maybe you should indicate it refers to [ALT].

But we have a long list of mapping systems, do you want all of them to be listed?

> "4.  The Map-Request packet is delivered to the right ETR with the help of the mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing topology.) In any case, when the Map-Request arrives …"

Well it does not capture the fact that the Map-Request can be delivered via the underlying routing system. I will add a refernece to ALT though from your first comment.

> This is just a comment, but FWIW, I am not super happy about the way the caching is an integral part of the specifications for LISP. Fundamentally, you could have used two orthogonal tools for dealing with routing scalability: 1. have only a subset of routers have to deal with EID routing (the xTRs) and 2.

Which is the way LISP is designed.

> use caching for scaling these routers better. If we had done this, then we would have had a very easy

Which is also the way LISP is designed.

So I am not following you.

> answer to those who have criticized the caching approach over the years: it is optional and up to the implementors to use or not. The first tool would still have been a valid approach to make the Internet scale better, even if you never did any caching.

The map-cache is only in the ITRs and PITRs as you described in point 1. And with added stretch the ITRs and PITRs could have a default cache entry that encapsulates to a set of ETRs which can hold more cache entries, and so on. If one chose to deploy LISP in a hierarchical way.

> In any case, your description of the thins-to-test should probably say something about effects of caching.

We have added a lot of text to cover many concerns. After reading the entire document, let us know what you think. ;-)

> First, I think Step 8 should be slightly edited to cover the fact that some additional checks are being made. E.g., "The ETR receives these packets directly (since ...), checks the validity of the addresses used in the packet, strips the LISP header and …"

I will add "checks the validity of the addresses" and of course keep the text that follows Step 8.

> Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to  source RLOC?

Because this is work still in progress.

> For interoperability, wouldn't it be cleaner to have a MUST here? How would I otherwise know if I can send an IPv4-in-IPv6 packet to a destination?

I can change to MUST.

> This feels odd, as there is no explanation in this point about what you do with IPv6. Maybe a sentence on IPv6 should be added?

It is explained in the MTU section. I think you may have not gotten there yet?

> I'm sure the details on IPv6 follow later in the document, but I suspect that other readers would be wondering here in the same way as I am.

Yes, they do.

> I'm reading on…

Thanks.

Dino

> 
> Jari
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Oct 2011 22:04:25 +0300

Continuing my review:

Technical:

> LISP Nonce:  The LISP nonce field is a 24-bit value that is randomly
> generated by an ITR when the N-bit is set to 1.  The nonce is also
> used when the E-bit is set to request the nonce value to be echoed
> by the other side when packets are returned.  When the E-bit is
> clear but the N-bit is set, a remote ITR is either echoing a
> previously requested echo-nonce or providing a random nonce.  See
> Section 6.3.1  <http://tools.ietf.org/html/draft-ietf-lisp-15#section-6.3.1>  for more details.
>

I read 6.3.1 and this text but it was still unclear to me if the nonces are generated fresh on a per-packet basis, or if one nonce value is sent on a stream of packets until you see it echoed back.

Can you clarify?

>     When doing ITR/PITR encapsulation:
>
>     o  The outer header Time to Live field (or Hop Limit field, in case
>        of IPv6) SHOULD be copied from the inner header Time to Live
>        field.
>

Just checking: this happens *after* you have decremented the TTL/HL as you were making a forwarding decision for the packet. So when the packet passes through an ITR, the outer IP header has a TTL that is decremented by one compared to the original packet, when looking at the packets on the wire. Right?

>     Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
>     after decapsulating, the net effect of this is that the new outer
>     header will carry the same Time to Live as the old outer header.
>

This seems wrong. Shouldn't the TTL be decremented even in this situation? But I'm sure you thought about this. What am I missing?

> The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
> field and the IPv6 Traffic Class field [RFC3168  <http://tools.ietf.org/html/rfc3168>].  The ECN field
> requires special treatment in order to avoid discarding indications
> of congestion [RFC3168  <http://tools.ietf.org/html/rfc3168>].  ITR encapsulation MUST copy the 2-bit ECN
> field from the inner header to the outer header.  Re-encapsulation
> MUST copy the 2-bit ECN field from the stripped outer header to the
> new outer header.  If the ECN field contains a congestion indication
> codepoint (the value is '11', the Congestion Experienced (CE)
> codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
> the stripped outer header to the surviving inner header that is used
> to forward the packet beyond the ETR.  These requirements preserve
> Congestion Experienced (CE) indications when a packet that uses ECN
> traverses a LISP tunnel and becomes marked with a CE indication due
> to congestion between the tunnel endpoints.

This works for routers that do not participate in ECN process themselves. I suppose it is theoretically possible that an xTR would also be doing ECN. Perhaps you could add to the end of this paragraph: "In addition, at the end of the process specified above, an ECN-capable xTR may perform its own modification of the ECN bits per [RFC3168], when it detects congestion.

> An ITR that is configured with mapping database information (i.e. it
> is also an ETR) may optionally include those mappings in a Map-
> Request.  When an ETR configured to accept and verify such
> "piggybacked" mapping data receives such a Map-Request and it does
> not have this mapping in the map-cache, it may originate a "verifying
> Map-Request", addressed to the map-requesting ITR.  If the ETR has a
> map-cache entry that matches the "piggybacked" EID and the RLOC is in
> the locator-set for the entry, then it may send the "verifying Map-
> Request" directly to the originating Map-Request source.  If the RLOC
> is not in the locator-set, then the ETR MUST send the "verifying Map-
> Request" to the "piggybacked" EID.  Doing this forces the "verifying
> Map-Request" to go through the mapping database system to reach the
> authoritative source of information about that EID, guarding against
> RLOC-spoofing in in the "piggybacked" mapping data.

I want to understand this better and I guess reading to the end of the document will answer some of my questions. But as a general rule, I think we should not trust other nodes in the network to claim alternative addresses for themselves, unless we can somehow verify (via return routability or via mapping data base) that they appear to really be at that address. So I am wondering if the "may originate" should become "originates". But I'm reading on.

> Weight:  when priorities are the same for multiple RLOCs, the weight
> indicates how to balance unicast traffic between them.  Weight is
> encoded as a relative weight of total unicast packets that match
> the mapping entry.  For example if there are 4 locators in a
> locator set, where the weights assigned are 30, 20, 20, and 10,
> the first locator will get 37.5% of the traffic, the 2nd and 3rd
> locators will get 25% of traffic and the 4th locator will get
> 12.5% of the traffic.  If all weights for a locator-set are equal,
> receiver of the Map-Reply will decide how to load-split traffic.

I am  surprised by the last sentence. Do you really mean that the receiver has the power to distribute, e.g., all traffic to the first locator? Or that the load-split will be equal among the locators? If you mean the former, how do I signal that I desire an equal load split? Send 49-51?

Editorial:

>     UDP Length:  The UDP length field is for an IPv4 encapsulated packet,
>        the inner header Total Length plus the UDP and LISP header lengths
>        are used.  For an IPv6 encapsulated packet, the inner header
>        Payload Length plus the size of the IPv6 header (40 bytes) plus
>        the size of the UDP and LISP headers are used.  The UDP header
>        length is 8 bytes.
>

I had trouble parsing this text. The first sentence seems to say that the is only for IPv4, but I think you mean that the values are calculated in different ways for IPv4 and IPv6.

Please clarify/reformulate.

> The format of the
> last 4 bytes of the LISP header would look like:
>
>
>       x x x x 1 x x x
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |N|L|E|V|I|flags|            Nonce/Map-Version                  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                 Instance ID                   |     LSBs      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

... format of the last 8 bytes of the LISP header ....

>     M: When set, it indicates a Map-Reply Record segment is included in
>        the Map-Request.

Unlike other bits this one has no name. Or is it the "Map-Reply Record Bit"?

>     S: This is the SMR bit.  SeeSection 6.6.2  <http://tools.ietf.org/html/draft-ietf-lisp-15#section-6.6.2>  for details.
>

Please expand SMR, as this is the first time this abbreviation appears in the document.

>     S: This is the SMR bit.  SeeSection 6.6.2  <http://tools.ietf.org/html/draft-ietf-lisp-15#section-6.6.2>  for details.
>
>     s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
>        sending a Map-Request in response to a received SMR-based Map-
>        Request.

The naming looks somewhat odd. Maybe SMR-request and SMR-response bits, or Solicited Map Request bit and Solicited Map Request Response bit...

> IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
> additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
> present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
> Address) pair must always be encoded.  Multiple ITR-RLOC Address
> fields are used so a Map-Replier can select which destination
> address to use for a Map-Reply.  The IRC value ranges from 0 to
> 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
> and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.
>

Perhaps you should explicitly say that value 0 means there are 1 ITR-RLOC addresses.

(You say only that "At least one pair must always be encoded", but does that mean that value 0 is disallowed or that it means 1 pair?)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Oct 2011 23:34:26 +0200

Still more parts in my review. I have now read until the beginning of Section 6.3.1. Some of these comments may change as I have read to the end of the document.

Technical:

>     When an ETR is misconfigured or compromised, it could return coarse
>     EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
>     cover EID-prefixes which are allocated to other sites redirecting
>     their traffic to the locators of the compromised site.
>
>     To solve this problem, there are two basic solutions that could be
>     used.  The first is to have Map-Servers proxy-map-reply on behalf of
>     ETRs so their registered EID-prefixes are the ones returned in Map-
>     Replies.  Since the interaction between an ETR and Map-Server is
>     secured with shared-keys, it is more difficult for an ETR to
>     misbehave.  The second solution is to have ITRs and PTRs cache EID-
>     prefixes with mask-lengths that are greater than or equal to a
>     configured prefix length.  This limits the damage to a specific width
>     of any EID-prefix advertised, but needs to be coordinated with the
>     allocation of site prefixes.  These solutions can be used
>     independently or at the same time.
>
>     At the time of this writing, other approaches are being considered
>     and researched.
>

There are obvious remaining issues with these solutions. Map-Servers may also be compromised, it is not clear that site prefix allocations have all equal size, ETRs may still return prefixes for someone else, etc. Have these been described in the security considerations section?

> S:   This is the Security bit.  When set to 1 the field following the
>       Reserved field will have the following format.  The detailed
>       format of the Authentication Data Content is for further study.

For further study, as in not defined by any of the LISP documents currently being published? It might be more appropriate to say "This contents of this field are reserved for future use and no current authentication data formats are defined."  And the implications should be described somewhere in security considerations section or the overall list of issues that need further work. (Or if this is actually defined somewhere, say "The detailed format of the field is described in [normative reference].")

And why is this definition different from other places where an authentication data field was included?

>     2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
>         message for an RLOC it is using.  This indicates that the RLOC is
>         likely down.
>

There is obviously a need to soften the impact spurious or spoofed ICMP messages. There is probably a TCP RFC somewhere where you can copy some current advise wrt. trusting ICMP error messages.

> When a bit goes from 1 to 0, the ETR will
> refrain from encapsulating packets to an RLOC that is indicated as
> down.

Some considerations might be necessary for conflicting information. For instance, what do you do if you receive a packet from a locator that is claimed to be down by another ITR?

Also, I do not fully understand what happens when you include the map version numbers in a LISP packet (V=1) and no nonce. Can off-the path attackers spoof a packet that claims to come from an ITR and which changes the locator status bits? That would open an ETR up for believe anyone in the Internet. Or am I missing something?

Editorial:

>       10.0.0.0/8
>       10.1.0.0/16
>       10.1.1.0/24
>       10.1.2.0/24
>
>     A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
>     count of 1 to be returned with a mapping record EID-prefix of
>     10.1.1.0/24.

This is just a comment, but I would personally use the IPv4 example address ranges for these sorts of examples, particularly given that both identifiers and locators are normally globally reachable addresses.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2011 15:13:24 +0300

Dino,

> But they don't know they are RLOC addresses. All end-systems assume is that addresses they put int destination address fields will make it to the destination. So if the address is an RLOC, the unde…

That makes sense. Please consider if you want to modify the text somehow; currently you are saying that hosts only send to EIDs. That is of course normally the case, but other cases will also happen and the routing should still work as expected. This is just a comment from me though, not a blocking issue.

> Hosts have EIDs assigned to them (when they are resident in a LISP site), IGP routers have EIDs assigned to them, and LISP routers have both EIDs and RLOCs assigned to them.

OK

>> Note: I'm not asking for any new functionality, just a statement about the expectations.

Fine. Can we state that? At least this reader was wondering if a router needed something special to be handle the selection. I'm of course very glad that the answer is no.

> We thought long and hard about this and wanted to mandate to indicate the seriousness of not going overboard with encapsulation. Now I know implementors can ignore specs, but for the record when it…

OK

>>>         used to do this is not described in this example.  See [ALT<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-ALT>] or
>>>         [CONS<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-CONS>] for possible solutions.
>>>

> Well it does not capture the fact that the Map-Request can be delivered via the underlying routing system. I will add a refernece to ALT though from your first comment.

OK

> The map-cache is only in the ITRs and PITRs as you described in point 1. And with added stretch the ITRs and PITRs could have a default cache entry that encapsulates to a set of ETRs which can hold…

This isn't a very urgent discussion because my comment was just that a comment. No need for you to change anything in the document. But I am still curious if you could implement a LISP router that simply held the entire mapping database and did not use any caching. But lets take the answer to that in some other thread to save time for moving the document forward...

Thanks.

> Because this is work still in progress.

I understand that, but accepting tunnel packets without this validation just seems pretty open to attacks. And this is not just about LISP. In general, every IETF technique that comes out may have vulnerabilities that cause trouble not just for that technology but also for other things in the Internet. I'm worried that this coyld be an attack vector to attack other things in the Internet in the future. Can we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much happier with that...

Thanks.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Oct 2011 10:04:40 -0700

> Fine. Can we state that? At least this reader was wondering if a router needed something special to be handle the selection. I'm of course very glad that the answer is no.

I added a sentence to the first bullet.

> I understand that, but accepting tunnel packets without this validation just seems pretty open to attacks. And this is not just about LISP. In general, every IETF technique that comes out may have vulnerabilities that cause trouble not just for that technology but also for other things in the Internet. I'm worried that this coyld be an attack vector to attack other things in the Internet in the future. Can we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much happier with that…

I hear you loud and clear. But no one may implement this beacuse it is hard and expensive. We need to solve it another way and we are not ready to document it yet.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Oct 2011 13:55:11 -0400

Given that, as far as I can tell, failing to perform the source checks 
leaves the site using the weak ETR at risk, but does not harm anyone else,
and given that this is experimental,
it seems sufficient to leave the text the way it is.

Yours,
Joel

...

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Oct 2011 23:24:12 +0300

Joel, Dino:

Not doing source address checks is not hurting just you as a receiver, but also whoever gets the response packet. It is hurting the rest of the Internet. Basically, a way to circumvent all the ingress filtering that exists in the Internet today.

Note that I was not suggesting a MUST. I understand that the implementation may be costly, and that is why I was suggesting a SHOULD.

Jari

On 27.10.2011 20:55, Joel M. Halpern wrote:
> Given that, as far as I can tell, failing to perform the source checks leaves the site using the weak ETR at risk, but does not harm anyone else,

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Oct 2011 13:43:48 -0700

I'll change to SHOULD. You make good points.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Oct 2011 09:31:07 -0700

LISP introduces the term "reencapsulating", and this is a
useful term with practical application. However, LISP also
uses the term "recursive (enapsulation)" in a way that is
different than its uses elsewhere such as in RFC2473.

What LISP is calling "recursive (encapsulation)" is called
"nested encapsulation" in RFC2473, and it has many practical
applications such as for traffic engineering. Indeed, the
term "nested" is also used in other practical contexts,
including "Nested Nemo".

But, RFC2473 goes on to define "recursive encapsulation"
as a harmful condition that arises from misconfigurations,
routing loops, etc. In the RFC2473 terminology, nested
encapsulation is a useful scenario that has a healthy
terminating condition, whereas recursive encapsulation
is unhealthy and, if left unchecked, results in an
infinite loop.

I would like to suggest that the LISP authors consider
altering their terminology to use the term "nested" to
refer to a healthy application of multiple layers of
encapsulation and to use the term "recursive" to refer
to an unhealthy application, i.e., the same as the terms
are used elsewhere.

Thanks - Fred
[email-masked]