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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi again,

please see below.

> Am 11.09.2018 um 18:45 schrieb Dino Farinacci <[e-mail]>:
> 
> 
>>> 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).

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.

Please note that I actually pointer to a wrong section in RFC6040 above. It should of course be 4.2 (and not 3.2).

> 
>>> 
>>> 
>>>> 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."
> 
>>> 
>>>> 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.

> 
>>> 
>>>> 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



> 
> Dino
> 
> 
>