Re: [lisp] Confirm/Deny changes on draft 6830bis

[Albert Cabellos <[e-mail]>]

Hi all

Thanks for all the comments, from my understanding of this thread the
following list of items *seem* to have rough consensus (all except B -
change definitions for EID and RLOC).

Joel, Luigi->How should we proceed now?

Albert

---

A.- Remove definitions of PA and PI

C.- In section 5.3, change the description of the encap/decap operation
concerning how to deal with ECN and DSCP bits to (new text needs to be
validated by experts):

When doing ITR/PITR encapsulation:


o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case
of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.


o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.


o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [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.


When doing ETR/PETR decapsulation:


 o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
when the Time to Live value of the outer header is less than the Time to
Live value of the inner header.  Failing to perform this check can cause
the Time to Live of the inner header to increment across
encapsulation/decapsulation cycles.  This check is also performed when
doing initial encapsulation, when a packet comes to an ITR or PITR destined
for a LISP site.


o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.


o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. 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 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.


Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
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 minus 1.


Copying the Time to Live (TTL) serves two purposes: first, it preserves the
distance the host intended the packet to travel; second, and more
importantly, it provides for suppression of looping packets in the event
there is a loop of concatenated tunnels due to misconfiguration.  See
Section 18.3 for TTL exception handling for traceroute packets.


D.- Simplify section ‘Router Locator Selection’ stating that the data-plane
MUST follow what´s stored in the map-cache (priorities and weights), the
remaining text should go to an OAM document.

E.- Rewrite Section “Routing Locator Reachability” considering the
following changes:

*    Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and
Echo-Nonce
*    Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3
(hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a
response) and RLOC probing

F.- Move Solicit-Map-Request to 6833bis

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document


On Fri, Jan 26, 2018 at 8:20 PM, Dino Farinacci <[e-mail]> wrote:

> Thanks for the detail review Padma. A new update to -09 is enclosed with a
> diff file. I will wait until next week to post.
>
> I have reflected all of your comments and most of Luigi’s comments. The
> only issues open are:
>
> (1) Section movement from RFC6830 to RFC6833.
>
> (2) If an OAM document is needed.
>
> Waiting for more working group concensus on this.
>
> > Dear Dino and Albert
> >
> > The doc reads well.
> > Please find thereafter some comments on the version- 09 you posted on
> the list
> >
> > Page 4
> > "Client-side:  Client-side is a term used in this document to indicate a
> connection initiation attempt by an EID."
> > PPE 1: Strictly speaking the EID is just an identifier and does not
> initiate anything. Suggest something like this.
> >
> > "Client-side:  Client-side is a term used in this document to indicate a
> connection initiation attempt by the end system (represented by an EID)”
>
> Fixed. Put in your suggestion.
>
> > Page 6
> > The source EID is obtained via existing mechanisms used to set a host's
> "local" IP address.  An EID used on the public Internet must have the same
> properties as any other IP address used in that manner; this means, among
> other things, that it must be globally unique.
> >
> > PPE 2: Shouldn't these two be MUST rather than must? Suggestion below
> >
> > The source EID is obtained via existing mechanisms used to set a host's
> "local" IP address.  An EID used on the public Internet MUST have the same
> properties as any other IP address used in that manner; this means, among
> other things, that it MUST be globally unique.
>
> Changed.
>
> > Page 8
> > An EID maps to one or more RLOCs.
> > PPE 3: Seems to contradict earlier explanation on negative mapping entry
> where it is possible that an EID has NO RLOC.
>
> I changed to “zero or more RLOCs.”.
>
> > Page 8
> > When using multiple mapping database systems, care must be taken to not
> create re-encapsulation loops through misconfiguration.
> >
> > PPE 4: Suggest to add "re-encapsulation" in the list in Security
> Considerations section as this is an exploit possibility.
>
> I have removed the sentence. Because it actually is not true. If you use
> different mapping systems and circuitious forwarding occurs. The packet
> travels only until its TTL reaches 0. Using the rules for copy inner to
> outer and outer to inner during RTR re-encapsulation applies.
>
> > Page 13
> > "gleaned" mapping
> >
> > PPE 5: Suggest adding “glean mapping” in the definition section.
>
> Changed.
>
> > Page 17
> > "The KK-bits are a 2-bit field used when encapsualted packets are
> encrypted."
> >
> > PPE 6: Nit - Typo "encapsualted" -> “encapsulated"
>
> Fixed.
>
> >
> > Page 20
> > "When the lookup succeeds, the locator-set  retrieved from the map-cache
> is used to send the packet to the EID's topological location."
> >
> > PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency
> with rest of document.
>
> Thanks. Done.
>
> >
> > Page 23
> > "The server-side sets a Weight of 0..."
> > PPE 8: Nit - For consistency in text change to "Weight of zero”.
>
> Changed.
>
> > Page 23
> > "Control is shared by the server- side determining the list and the
> client determining load  distribution."
> >
> > PPE 9: Suggest use of "Client-side"
> >
> > "Control is shared by the server- side determining the list and the
> client-side determining load distribution.”
>
> Done.
>
> > Page 24
> > When a verified Map-Cache entry is stored, data gleaning no longer
> occurs for subsequent packets that have a source EID that matches
> > the EID-Prefix of the verified entry.[PE1]   This "gleaning" mechanism
> is OPTIONAL.
> >
> > PPE 10: In section 16.2 later gleaning is used as a solution.  Changes
> in the gleaned info could be an interesting way to update the cache fast
> …however this text make it sound that this is not an option after first
> packet.
>
> It is an option when the ETR has no mapping to return packets. Once a
> mapping is cache, there is no point to glean since the mapping system
> verified the information the same as in the map-cache.
>
> >
> > Page 25
> > "Note that trusting ICMP messages may  not be desirable, but neither is
> ignoring them completely. Implementations are encouraged to follow current
> best practices in treating these conditions."
> >
> > PPE 11: A reference would be useful if possible.
>
> Added draft-ietf-opsec-icmp-filtering.
>
> > Page 25
> > "An ITR that participates in the global routing system can determine
> that an RLOC is down if no BGP Routing Information Base (RIB) route exists
> that matches the RLOC IP address."
> >
> > PPE 12: Isn't this true for any protocol entry not just a BGP entry? We
> are really trying to determine if there is no route whatever the protocol.
>
> Yes, we can generalize this. I changed text.
>
> > Page 38
> > "For a more detailed networkd design deployment recommendation, refer to
> [RFC7215]."
> >
> > PPE 13: Nit typo "netword"-> “network"
>
> Changed.
>
> > Page 40
> > "By having the PE be the first router on the path to encapsulate, it can
> choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for
> a new encapsuluation path to the destination end site."
> >
> > PPE 14: Nit Typo "encapsuluation" -> “encapsulation"
>
> Changed.
>
> > Page 43
> > "If the attacker spoofs the source RLOC, it can mount a DoS attack by
> redirecting traffic to the spoofed victim;s RLOC, potentially overloading
> it."
> >
>
> > PPE 15: Nit  typo "victim;s" -> “victim’s”
>
> Changed.
>
> Dino
>
>
>
>
>
>
>
>
>
>
>
>
>