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

["Joel M. Halpern" <[e-mail]>]

Assuming Luigi agrees, there should be a version of this dcoument 
submitted that incorporates what Dino did for A and C, and addresses D - G.

Yours,
Joel

On 1/28/18 10:07 PM, Dino Farinacci wrote:
> Note A and C are addressed in the -09 revision I sent out in Friday.
> 
> Dino
> 
> On Jan 28, 2018, at 5:57 PM, Albert Cabellos <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>> 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] 
>> <mailto:[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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>