Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6830bis-16: (with DISCUSS and COMMENT)

Luigi Iannone <ggx@gigix.net> Tue, 18 September 2018 08:14 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66C2128D0C for <lisp@ietfa.amsl.com>; Tue, 18 Sep 2018 01:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p4jr4o_FTcM for <lisp@ietfa.amsl.com>; Tue, 18 Sep 2018 01:14:50 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DE3127AC2 for <lisp@ietf.org>; Tue, 18 Sep 2018 01:14:50 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id e1-v6so1035746wrt.3 for <lisp@ietf.org>; Tue, 18 Sep 2018 01:14:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OWp4gjnGkoN1ViHm1rF9jmBG14eISnX+wSHD726xAD4=; b=QT29CSjg+5gAsupAsfyAmbiNzEpy4FXCcyrg/EKPU95GsTLi2S/Pjh+8L4svkPL4XW yezhCKvj7k255Gwa9WCe7KXKKZKwjiUEC1/IUlC7ijsWEdi6SjHZn8LWeYYOSJxA+22o Z7XaVAway47Pg5qsGT4G6/hMt0pxsfzjvQH/78JSjKm+ySeIDj/oDnrTuINzYMAWGR6o ZtPbxnn6zGpva776RtIkCIqc/cvH75PhelwwezznIudnRpM8BCs5L/A2PEXCMvhedowJ 31ShKcTJvg6htFacT6Qeijn4CmFZ5CKmVRnPzYtWW/i06miWfQI+/8SHpiPL5x9iXfxY X6jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OWp4gjnGkoN1ViHm1rF9jmBG14eISnX+wSHD726xAD4=; b=AP/dEX7eWS+aWsocse7xifQytmClCPiVkIOqDHd2p9ZqBweLUhHzaExkPlwra/7dYV lB8Zc5GJhYxzGJfIhrvzGDVoa2q7YJl3z0nqGk3m7SDYAJpihSpt40wp1SuYbx3MpX7Z BQIL1IKiZtAMNW1hJi890MnGUhva981t4yiPH0sSsI/t5HTj+Yc86Vu58uBp89mI+4zK p1NAOKz6xcpHUjNvuLGz35SSC8oHS/mri930K/8Itefukz1Zl8WW2GtxYhWTF4ZqdFBv LZfVTbtE+U6iZnS4Ni0zGS/B1bAj7sOzeERPRagqNNmdH3prVnWUGFGY+lZMWvP7ERtt 84iA==
X-Gm-Message-State: APzg51CwJXmNUCgTejEoFT3QhStLapgixapyb9jQfOEk/mdstLDfuCDp YKka8d4+PTgP1X9oJ8YSmUrFAg==
X-Google-Smtp-Source: ANB0VdaRVzl0tnR0x/Xdn4sIat0sCe8DygV0JPT6XOEwkCYHnJXHwkJIEUha0DGDfxIRQqOcULiDeA==
X-Received: by 2002:a5d:4e0a:: with SMTP id p10-v6mr21361778wrt.48.1537258488526; Tue, 18 Sep 2018 01:14:48 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:25f4:45e1:39b9:1fee? ([2001:660:330f:a4:25f4:45e1:39b9:1fee]) by smtp.gmail.com with ESMTPSA id k5-v6sm13725865wrm.96.2018.09.18.01.14.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 01:14:47 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <D4593D6E-19F0-48B4-917D-A755FD4C7B4E@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_656AF8F2-D1D1-473D-ACDF-2A4D695242AF"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 18 Sep 2018 10:14:52 +0200
In-Reply-To: <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net>
Cc: Dino Farinacci <farinacci@gmail.com>, lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG <iesg@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <DDA9C261-44DD-4389-9463-3A84E4C176BB@gmail.com> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/H1335TRC2KHkIRA4b118zk_F97o>
Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 08:14:54 -0000

Dino, Mirja,

a couple of comments inline.

Thanks 

> On 17 Sep 2018, at 18:15, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> 
> Hi Dino,
> 
> unfortunately, I don’t think this is quite there yet. First of all, I have to say that I misread the original text which already says that only the CE should be copied which is at least mostly inline with RFC6040 already. However, I really would like the existing text to be clearer here (instead of just adding additional text).
> 
> Also you still need at least one reference to rfc3168 because that’s the spec that defines the mechanism and IP bits.
> 
> Let me propose something:
> 
> For encapsulation:
> OLD
> "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.“
> PROPOSED
> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>      of the IPv6 'Traffic Class' field) [RFC3168] requires special treatment in
>      order to preserve the use of ECN on the path.
>      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>      header to the outer header, inline with the ’Normal Mode’ in section 4.1 
>      of [RFC6040].  Re-encapsulation SHOULD follow the decapsulation as described 
>      below and then 2-bit 'ECN' field from the stripped inner header to the 
>      new outer header.“
> 
> For decapsulation:
> OLD
> "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.“

@Mirja: As Dino pointed out the last sentence is unclear.


> PROPOSED
> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>      of the IPv6 'Traffic Class' field) requires special treatment on 
>      decapsulation in
>      order to avoid discarding indications of congestion, 
>      inline with section 4.2 of [RFC6040]. If
>      the 'ECN‘ field of the outer header contains a congestion indication 	
>      codepoint (the
>      value is '11', the Congestion Experienced (CE) codepoint) and the inner 
>      header indicates ECN support (either ECT(0) or ECT(1) codepoint is set), 
>      then ETR decapsulation MUST also set CE field in the inner header that is 
>      used
>      to forward the packet beyond the ETR.

@Mirja: So far so good. Is the equivalent of what is already there.

> If the inner packet is marked as non-
>      ECT but the outer header has the CE mark set, the packet MUST be dropped 
>      instead.

@ Mirja: How can this happen? As for your text we MUST copy inner CE to outer CE when encapsulating, so if the original packet does not support ECN the outer header will state so and there will not be any CE mark set.


> Any discrepancy between the inner and outer header for non-ECT, 
>      ECT(0) and ECT(1) MUST NOT be copied from the outer header. These 
>      requirements preserve
>      CE indications when a packet that is ECN-capable traverses a LISP tunnel
>      and becomes marked with a CE indication due to congestion between
>      the tunnel endpoints or transforms an CE into loss if that packet is not 
>      ECN-capable conserving the congestion indication towards a non-ECN enables 
>      endpoint."
> 
> Please also remove the duplicated text after these bullet lists in the draft!
> 
> Further I believe my discuss points 2)

@ Dino: this point is about the following bullet in section 5.3:

 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.


You need to delete the trailing “considering the exception listed below” because there is no exception listed.


> and 4)

@ Mirja: This point is about all packets of the same flow having the same source port number. Version -17 includes the following sentence in section 12:

The source port
   SHOULD be the same for all packets belonging to the same flow.


As you have requested.


> are not fully resolved yet. Also I would like to at least see more explanation about the approach for extensibility that was taken in this doc (point 6).

@Mirja: Would you mind being more explicit? I fail to see the exact point you are trying to make.

Dino already explained the rationale of why LISP is as it is. We can discuss endlessly whether was a good or bad choice, but it is what it is and we cannot change it now.

IMHO, it is not worth to add any discussion on this matter in this document. 
Unless we just keep it to a simple sentence like: 

“Extension to the LISP header described in this document can be achieved using the LISP General Protocol Encapsulation mechanism [draft-ietf-lisp-gpe]." 


Ciao

L.




> Mirja
> 
> 
>> Am 12.09.2018 um 23:30 schrieb Dino Farinacci <farinacci@gmail.com>om>:
>> 
>>> Hi again,
>>> 
>>> please see below.
>> 
>> Thanks for the ongoing discussion Mirja. See a new diff file enclosed as a proposed -18 update. Let me know if the text I added to address your comments are sufficient.
>> 
>> I believe (but could be wrong) that this should be the last set of comments to 6830bis. But I have not seen any acks from Alvaro if we addressed all his comments (specifically for 6830bis).
>> 
>>> 
>>>> Am 11.09.2018 um 18:45 schrieb Dino Farinacci <farinacci@gmail.com>om>:
>>>> 
>>>> 
>>>>>> Well it doesn’t have to be. I am a bit hesitant to just point to another long complicated RFC. This text has gone through review for quite a long time and many ECN experts decided we should write it this way. And this text did go through IESG review when RFC6830 was made experimental RFC.
>>>>> 
>>>>> Procedere explained in RFC6040 are actually not that complicated. It’s mainly the table provided in section 3.2. Please have a look at the draft. However, I disagree that it „negative“ to point for this part to another RFC. This is not a unique problem, that’s why we have RFC6040 and all approaches that face this problem should point to RFC6040 and implement the same strategy.
>>>> 
>>>> I am just worried it will be ignored because there are implementations out there that do what they already do. If we want to suggest to consider the procedures in RFC6040, I am okay with that, but you need to provide the wording because I certainly don’t want it too strong.
>>> 
>>> Actually the behavior as currently described in the lisp draft is not even complainant with rfc3138, however, rfc3168 is updated by rfc6040. The encapsulation in the lisp draft behavior is already what RFC6040 described; so that’s good. However, the decapsulation is neither what RFC3168 nor rfc6040 says. Therefore this must be fixed and I guess a bis doc is also the best chance we get to fix these incorrect implementation then. If you are worried that this will be ignored, you should mention it explicitly in section 18 (Changes since RFC 6830).
>> 
>> The working group made this decsision back in 2009 when the LISP WG was formed. Actually earlier when we did the initial work in the IRTF RRG. RFC3168 was published in Sep 2001. But note one of the authors, David Black, offered the text you see in the document rewgarding ECN handling.
>> 
>> So by doing this update, we ARE going to create a implementation incompatibility.
>> 
>>> There is no matter about the wording being too strong or whatever, RFC6040 is very clear about the correct behavior and that is exactly what needs to be implemented. Please go ahead and read RFC6040. If you need further help, please ask an ECN expert for help, e.g. Bob Briscoe who is the author of RFC6040.
>> 
>> Check the diff file to see if you are okay with the new text added. It WAS NOT simple because there are a number of cases that need to be described that doesn’t contradict RFC6040 that I do not want to repeat.
>> 
>>> Please note that I actually pointer to a wrong section in RFC6040 above. It should of course be 4.2 (and not 3.2).
>> 
>> Okay, that makes more sense now. I was confused.
>> 
>>>>>> 
>>>>>> 
>>>>>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while
>>>>>>> "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.
>>>>>> 
>>>>>> This is discussed in length. I don’t know how you could have missed this.
>>>>> 
>>>>> I didn't miss that discussion but the text got fixed incorrectly because it doesn’t not address IPv4 through the whole text. Please have a look and fix that as well. I think this is mainly an editorial issue but and important one to fix.
>>>> 
>>>> I am sorry. I don’t know what you think is wrong. Please point to the text specifically.
>>> 
>>> Sec 7.2:
>>> "   2.  When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
>>>     with the DF bit set to 1, exceeds what the core network can
>>>     deliver, one of the intermediate routers on the path will send an
>>>     ICMPv6 "Packet Too Big" message to the ITR.  The ITR will parse
>>>     ^^^^^^^^^^^^^^^^^^^^^^
>>>    there will be no ICMPv6 message is the packet was IPv4
>>> 
>>>     the ICMPv6 message to determine which Locator is affected by the
>>>     effective MTU change and then record the new effective MTU value
>>>     in the Map-Cache entry.
>>> 
>>> 3.  When a packet is received by the ITR from a source inside of the
>>>     site and the size of the packet is greater than the effective MTU
>>>     stored with the Map-Cache entry associated with the destination
>>>     EID the packet is for, the ITR will send an ICMPv6 "Packet Too
>>>                                                 ^^^^^^^^^^^^^^^^^^^
>>> 
>>>     Big" message back to the source.  The packet size advertised by
>>>     the ITR in the ICMPv6 message is the effective MTU minus the LISP
>>>     encapsulation length.”
>> 
>> This is now fixed. I now understand your comment. Please check the diff file enclosed.
>> 
>>>> 
>>>>>> 
>>>>>>> 6) And now the more-discussion-needed point:
>>>>>>> So my underlying concern is the same as brought up by the TSV-ART review that
>>>>>>> lisp information are not end-to-end integrity protected or authenticated.
>>>>>> 
>>>>>> I would like you to be more specific. Beacuse there is a lot of security in the protocol and we believe the current drafts, in their entirety, inicdate so.
>>>>> 
>>>>> I was thinking about the option to add an authenticated hash, anyway…
>>>> 
>>>> LISP uses lisp-crypto (RFC8061) which uses AEAD.
>>> 
>>> I think the pity here is that RFC8061 is still a separate optional RFC. I would have expected to have this integrated into rfc6830bis and make it mandatory to implement if not mandatory to use.
>> 
>> Agree. I don’t know what to tell you. But as you might now, there is a tradeoff between privacy and monitoring/lawful intercept that is being made and we know there are strong camps on each side.
>> 
>> You might have heard me say it at a recent IETF plenary “everything should be encrypted, period”. So you know what camp I’m in.  ;-)
>> 
>>> 
>>>> 
>>>>>> 
>>>>>>> However, while briefly thinking about how this could be eventually realized, I
>>>>>>> noticed that there is actually no mechanism to extend the LISP header in any
>>>>>> 
>>>>>> Right, by design so it is efficient for hardware AND software forwarding. But we do have the LISP-GPE header that can be used for extensions. But that has limited deployment.
>>>>>> 
>>>>>>> way. There is no version, no option and the LISP header seems to have a fixed,
>>>>>> 
>>>>>> We decdied as a working group that the UDP port number would indicate what header follows and therefore what LISP version is used.
>>>>> 
>>>>> Okay, that needs to be explained in the doc!
>>>>> 
>>>>> Mirja
>>>> 
>>>> The document says that UDP port 4341 is assigned and when so, the LISP header as docmented is used. We shouldn’t just encourage versioning if the philosophy it not to churn often.
>>> 
>>> Okay, that is actually not possible based on the recommendation in RFC6335:
>>> 
>>> "   o  IANA strives to assign only one assigned port number for all
>>>    variants of a service (e.g., for updated versions of a service).“
>>> 
>>> That means it is not possible to get another port number for a new version of lisp. You need a different version approach.
>>> 
>>> Mirja
>> 
>> The working group made this decsision back in 2009 when the LISP WG was formed. Actually earlier when we did the initial work in the IRTF RRG. RFC3168 was published in Aug 2011.
>> 
>> LISP-GPE is a variant of the the LISP data-plane, and it is using the same UDP port 4341. So we actually accomplished the reuse.
>> 
>> Dino
>> 
>> <rfcdiff-6830bis.html>
>> 
>> 
>