Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf-lisp-gpe-09: (with COMMENT)

["Fabio Maino (fmaino)" <[e-mail]>]

Hi Ben, 
Here is how we propose to move forward. 

Given that with LISP-GPE we have the opportunity to add additional protocol features defining new shim headers, we have removed the Nonce, Map-Versioning, and LSBs fields from the main LISP-GPE header. 

It will then be possible to define a LISP-GPE shim header that includes a 64-bit (or even 128-bit) Nonce, as well as a proper Map-versioning and LSBs fields. That could be done with an appropriate separate draft, that hopefully will address the concerns about those 3 features that have been expressed in the review of 6830bis. 

I have attached rev -11 of the draft and a diff file that reflects the approach above.

It'd be great to hear your thoughts. 

We will discuss this approach with the WG in Singapore, and if there's support, we could go to LC right after the meeting. 

Thanks,
Fabio

 





On 10/25/19, 5:20 PM, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-lisp-gpe-09: Abstain
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Thank you for addressing my Discuss-level points (I can accept that for the -09
    that RFC 8060 need not be a normative reference).  I am balloting Abstain because
    I am uncomfortable with only 16 bits of nonce, but I recognize that there is a need
    for this sort of encapsulation and it must fit within the constraints of the core protocol.
    Though, given Alissa's Discuss, it is technically still possible for the core protocol to
    grow a larger nonce that would alleviate my concerns.  But, since the issue stems from
    a different document (and because I did not raise the issue earlier), it is not appropriate
    for me to ballot Discuss on this document for that point.
    
    [original COMMENT section unchanged; contents presumably stale]
    
    Section 1
    
       LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
       has allocated all by defining a Next Protocol "shim" header that
    
    nit: allocated all of what?
    
    Section 3
    
    This is not exactly the responsibility of LISP-GPE merely because it
    allocates the last bit in this bitmap, but it seems like it would be quite
    useful to have a table of which combinations of values are valid vs.
    nonsensical, given the somewhat complicated interaction between some of
    these flag bits.
    
          Similarly, the encoding of the Source and Dest Map-Version fields,
          compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
          bits.  This still allows to associate 256 different versions to
          each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
          to inform commmunicating ITRs and ETRs about modifications of the
          mapping.
    
    Are we limited to 256 versions total, or is there some sort of larger
    version space that we truncate to send (a la a wraparound process)?
    I understand that map-versioning is primarily in a separate document but it
    seems important for this document to describe to what extent it is limiting
    functionality.
    
    Section 3.1
    
       To ensure that protocols that are encapsulated in LISP-GPE will work
       well from a transport interaction perspective, the specification of a
       new encapsulated payload MUST contain an analysis of how LISP-GPE
       SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
       Congestion Notification (ECN) bits whenever they apply to the new
       encapsulated payload.
    
    This MUST is duplicated in the next three paragraphs; I would suggest
    leaving this introduction as non-normative, with something like "needs to
    contain an analysis of how LISP-GPE will deal with [...]"
    Also, nit: "the outer UDP Checksum"
    
    Section 4
    
       When encapsulating IP packets to a non LISP-GPE capable router the
       P-bit MUST be set to 0.  [...]
    
       A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
       P-bit set to 1) to a non-LISP-GPE capable router.
    
    I'm failing to see how these two sentences are not redundant.
    
    Section 5.1
    
    Just to be clear, the intent is that if there is some non-IETF protocol
    that we want to encapsulate, we write a two-page Standards-Track RFC that
    says "this GPE codepoint means to do what this non-IETF document says"?
    
    Section 6
    
                           However, the use of common anti-spoofing
       mechanisms such as uRPF prevents this form of attack.
    
    I think "mitigates" is probably better than "prevents" in this case.
    
       LISP-GPE, as many encapsulations that use optional extensions, is
       subject to on-path adversaries that by manipulating the g-Bit and the
       packet itself can remove part of the payload.  Typical integrity
       protection mechanisms (such as IPsec) SHOULD be used in combination
       with LISP-GPE by those protocol extensions that want to protect from
       on-path attackers.
    
    The g-Bit is present in the Map-Reply message, which can in the general
    case be sent via triangle-routing, in which case the establishment and
    selection of IPsec security associations is somewhat nontrivial and
    probably does not quality as "typical", based on my limited experience.
    I think a more general scheme for providing integrity protection for
    mapping messages is needed as a mandatory mechanism, but that's a topic for
    the control-plane document so I will not belabor it here.