Subject: [lisp] AD review of draft-ietf-lisp (part 6)

From: Jari Arkko <[email-masked]>
Date: Sat, 22 Oct 2011 02:24:20 +0300

Technical:

Overall, the security considerations section is a bit thin. I don't think we need a lot of additional text, but there are some additional pieces of information that need to be added. Some suggested text below.

> The nonce, coupled
> with the ITR accepting only solicited Map-Replies goes a long way
> toward providing decent authentication.

Hmm. This is not really descriptive. How about this instead:

The nonce, coupled with the ITR accepting only solicited Map-Replies provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these Lisp mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible, but would already by itself be a denial-of-service attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking or redirecting traffic. Lisp relies on the correct operation of a BGP-based routing system [LISP-ALT], but so do the current Internet routing mechanisms.

> It is a good idea to have instrumentation in place
> to detect thrashing of the cache.  Implementation experimentation
> will be used to determine which cache management strategies work
> best.

Yes, but I think we should also acknowledge that defending against cache trashing attacks is hard:

    It is a good idea to have instrumentation in place
    to detect thrashing of the cache.  Implementation experimentation
    will be used to determine which cache management strategies work
    best. In general, it is difficult to defend against cache trashing attacks.

(Unless, of course, I'm missing some obvious schemes that show promise of avoiding some of these issues against determined attackers. It is also possible that if we described the situation in more detail, we'd be able to describe the threats in a more rational way. E.g., outsiders can cause some (limited) problems, insiders could cause big trouble but are generally a bit more trusted, etc.)

>     This experimental specification does not address automated key
>     management (AKM).BCP 107  <http://tools.ietf.org/html/bcp107>  provides guidance in this area.

Yes, but I think we should include two additional important pieces of information. 1. you need to acknowledge that you are not following BCP 107 in this case, as it requires AKM under certain conditions (we are within those conditions, right?). And 2) more importantly, you need to document the implications of not providing AKM. Personally, I do not necessarily consider it a panacea, and often the nonce etc. mechanisms are far more important. In any case, the reader needs to understand what we are losing without AKM.

> 13.  Network Management Considerations
>
>    Considerations for Network Management tools exist so the LISP
>    protocol suite can be operationally managed.  The mechanisms can be
>    found in [LISP-MIB] and [LISP-LIG].

It is good that you point to these specifications. I wonder if there are additional things you should say in this spec, however. Are there parameters that Lisp needs to operate? Are they and their default values described in LISP-MIB? There are many good pieces of advice about the management of a Lisp network in previous sections, should there be some kind of summary/pointers for these here as well?

Editorial:

> Return- Routability

s/- /-/

>     datragram.  If a LISP encapsulated packet arrives at an ETR, it MAY
>

datagram

> system [KARP  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-KARP>], [RPKI  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-RPKI>],
>     [BGP-SEC  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-BGP-SEC>], [LISP-SEC  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-LISP-SEC>],

s/[LISP-SEC],/[LISP-SEC]./

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2011 00:02:51 +0300

This is the last part of my review, as far as the actual document contents go. I will send another summary e-mail.

Technical:

> 14.1.  LISP Address Type Codes
>
>    Instance ID type codes have a range from 0 to 15, of which 0 and 1
>    have been allocated [LCAF].  New Type Codes MUST be allocated
>    starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
>    Type Codes 11 - 15 are available on a First Come First Served policy.
>
>    The following codes have been allocated:
>
>    Type 0:  Null Body Type
>
>    Type 1:  AFI List Type
>
>    See [LCAF] for details for other possible unapproved address
>    encodings.  The unapproved LCAF encodings are an area for further
>    study and experimentation.

To begin with, I did not understand this definition. I'm trying to understand where the LCAF draft actually makes the instance ID allocations, and I can't see it. In addition, the "Null Body Type" string only appears twice in this and the LCAF draft, and neither occurrence explains what it is. I think something is missing here.

Finally, I do not understand why this section is in -lisp. The string "LISP Address Type Code" does not appear in the rest of the document AFAICT. The allocations in the LCAF draft seem to be inside a format defined in that draft.  Shouldn't the IANA allocations and the creation of the registry be in that draft as well? This seems particularly important, given that the list of types in -lisp does not match the list in -lcaf.

Suggested edit: delete this section.

>
>     o  The following policies are used here with the meanings defined in
>        BCP 26  <http://tools.ietf.org/html/bcp26>: "Specification Required", "IETF Consensus", "Experimental
>        Use", "First Come First Served".
>

None of these terms are used in the rest of the document. (But see below.)

> 14.  IANA Considerations

This sections makes the right allocations from other, already existing registries (like UDP port numbers). But it should also define what the policies are for allocating new values with the various new number spaces that Lisp introduces:

- flags
- type
- reserved
- act
- unused flags
- ...

>     [BGP-SEC]  Lepinski, M., "An Overview of BGPSEC",
>                draft-lepinski-bgpsec-overview-00.txt  <http://tools.ietf.org/html/draft-lepinski-bgpsec-overview-00.txt>  (work in progress),
>                March 2011.
>
>     [KARP]     Lebovitz, G. and M. Bhatia, "Keying and Authentication for
>                Routing Protocols (KARP)Design Guidelines",
>                draft-ietf-karp-design-guide-02.txt  <http://tools.ietf.org/html/draft-ietf-karp-design-guide-02.txt>  (work in progress),
>                March 2011.

>     [RPKI]     Lepinski, M., "An Infrastructure to Support Secure
>                Internet Routing",draft-ietf-sidr-arch-13.txt  <http://tools.ietf.org/html/draft-ietf-sidr-arch-13.txt>  (work in
>                progress), February 2011.

I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LISP as specified in this document, or even to understand what Lisp is or its impacts.

>     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>                STD 13,RFC 1034  <http://tools.ietf.org/html/rfc1034>, November 1987.
>

If you look at the way this is referenced from the text, it is clear that this should be a non-normative reference.

       The host obtains
       a destination EID the same way it obtains an destination address
       today, for example through a Domain Name System (DNS) [RFC1034]
       lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.

>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>               A., Peterson, J., Sparks, R., Handley, M., and E.
>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>               June 2002.

Same as above.

>     [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
>                Traina, "Generic Routing Encapsulation (GRE)",RFC 2784  <http://tools.ietf.org/html/rfc2784>,
>                March 2000.
>

If you look at the way this is referenced from the text, I think this should be a non-normative reference.

   o  On an ITR, prepending a new IP header consists of adding more
       bytes to a MAC rewrite string and prepending the string as part of
       the outgoing encapsulation procedure.  Routers that support GRE
       tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
       support this action.

GRE is here use as an example, not as normative behavior.

>     [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
>                via IPv4 Clouds",RFC 3056  <http://tools.ietf.org/html/rfc3056>, February 2001.
>

Same as above.

>
>     [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
>                Optimization for Mobile IPv6",RFC 4866  <http://tools.ietf.org/html/rfc4866>, May 2007.

I think this one can be non-normative or even be removed, depending on how the mobility section rewrite goes.

>
>     [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
>                Workshop on Routing and Addressing",RFC 4984  <http://tools.ietf.org/html/rfc4984>,
>                September 2007.
>

Background. Non-normative.

>     [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>                NUMBERS
>                http://www.iana.org/assignments/address-family-numbers.
>
>     [AFI-REGISTRY]
>                IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>                NUMBER registryhttp://www.iana.org/assignments/
>                address-family-numbers/
>                address-family-numbers.xml#address-family-numbers-1.

Is there really no better reference for this, an RFC perhaps?

I wish there were... and that RFC could be put in to the normative-reference section. If there is no suitable RFC I'm fine with the current two references as-is.

>     [INTERWORK]
>                Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
>                "Interworking LISP with IPv4 and IPv6",
>                draft-ietf-lisp-interworking-02.txt  <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02.txt>  (work in progress).
>

I think this one should be normative. This is such a key piece of work to understanding Lisp, and the text seems to treat it as if it is a normative part. For instance:

   Proxy ITR (PITR):   A PITR is also known as a PTR is defined and
       described in [INTERWORK], a PITR acts like an ITR but does so on
       behalf of non-LISP sites which send packets to destinations at
       LISP sites.

>     [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
>                draft-ietf-lisp-ms-09.txt  <http://tools.ietf.org/html/draft-ietf-lisp-ms-09.txt>  (work in progress).
>

Isn't this normative as well? Here's an example of how the text refers to it:

   Map-Requests can also be LISP encapsulated using UDP destination port
    4342 with a LISP type value set to "Encapsulated Control Message",
    when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
    LISP encapsulated the same way from a Map-Server to an ETR.  Details
    on encapsulated Map-Requests and Map-Resolvers can be found in
    [LISP-MS].

>
>     [VERSIONING]
>                Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
>                Versioning",draft-ietf-lisp-map-versioning-01.txt  <http://tools.ietf.org/html/draft-ietf-lisp-map-versioning-01.txt>  (work
>                in progress).
>

I suspect this is normative, too. See Section 6.6.3.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Oct 2011 09:41:09 -0700

> The nonce, coupled with the ITR accepting only solicited Map-Replies provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It…

I will add this text modulo the last sentence. I don't understand how ALT plays into this. So I felt it was a random statement. Did you mean LISP relies on a secure mapping database system?

> (Unless, of course, I'm missing some obvious schemes that show promise of avoiding some of these issues against determined attackers. It is also possible that if we described the situation in more…

Schemes are work in progress and hence why we don't want to list them. We had mentioned this before from the Nanog-triggered thread which we moved over to the [email-masked] list.

> Yes, but I think we should include two additional important pieces of information. 1. you need to acknowledge that you are not following BCP 107 in this case, as it requires AKM under certain condi…

This text was created, accepted, and agreed upon from the security ADs. So I dare not to touch it.

> It is good that you point to these specifications. I wonder if there are additional things you should say in this spec, however. Are there parameters that Lisp needs to operate? Are they and their…

All described in the LISP-MIB, which is still ongoing. I will make sure we put any configuration guidelines in there.

> s/- /-/

Fixed.

>>    datragram.  If a LISP encapsulated packet arrives at an ETR, it MAY

Fixed.

> s/[LISP-SEC],/[LISP-SEC]./

Fixed.

Dino

> 
> Jari
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Oct 2011 09:54:29 -0700

> To begin with, I did not understand this definition. I'm trying to understand where the LCAF draft actually makes the instance ID allocations, and I can't see it. In addition, the "Null Body Type"…

The source-EID in an RLOC-probe may contain a null body encoding. Because there was no data packet that triggered this Map-Request. I will add that to the RLOC-probe section.

Instance-ID is defined in the LCAF draft as Type 2. Here is the packet format:

  Instance ID LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |    Rsvd1      |    Flags      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 2    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      Instance ID field including the AFI field itself.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [LISP] for details.

   AFI = x:  x can be any AFI value from [AFI].

   This LISP Canonical Address Type can be used to encode either EID or
   RLOC addresses.

> Finally, I do not understand why this section is in -lisp. The string "LISP Address Type Code" does not appear in the rest of the document AFAICT. The allocations in the LCAF draft seem to be insid…

We (the working group) have decided to put the in-charter values in this draft and keep the other values in the LCAF draft. So that is why values 0 and 1 are in this draft. Since instance-ID is part of a VPN use-case, this is why it is the next value assigned in the LCAF draft.

We received direction from Terry on this since he is expert in registries et al.

> None of these terms are used in the rest of the document. (But see below.)

That is Terry text and seems to be standard.

> - …

Terry needs to respond to this.

> I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LI…

Can yo and the chairs argue over this and make a decision. Then I will put it where you have agreed.

>   on encapsulated Map-Requests and Map-Resolvers can be found in

You guys decide where all of this should go (from my last comment to this line), and I'll make one change.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Oct 2011 13:52:32 -0400

Dino, are any of these ones we asked you to move around earlier for some 
reason?  (I want to try to avoid saying A, no B, no A...)

Assuming these were not previously moved for some reason, I am happy 
with most of Jari's suggests.

I do think referencing the registry for AFIs is the right thing. 
Referencing the RFC that defines the registry would merely cause an 
indirection, since what people generally need is the values.  If they 
need the underlying definition, they can follow the links from there.

I do not think the Interworking draft should be a normative reference. 
It is needed for understanding deployment with interworking.  But it is 
not needed for understanding the base LISP spec.

Yours,
Joel

On 10/27/2011 12:54 PM, Dino Farinacci wrote:
...
>>>                draft-lepinski-bgpsec-overview-00.txt<http://tools.ietf.org/html/draft-lepinski-bgpsec-overview-00.txt>   (work in progress),
>>>                March 2011.
>>>
>>>                draft-ietf-karp-design-guide-02.txt<http://tools.ietf.org/html/draft-ietf-karp-design-guide-02.txt>   (work in progress),
>>>                March 2011.
>>
>>>                Internet Routing",draft-ietf-sidr-arch-13.txt<http://tools.ietf.org/html/draft-ietf-sidr-arch-13.txt>   (work in
>>>                STD 13,RFC 1034<http://tools.ietf.org/html/rfc1034>, November 1987.
>>>
>>
>>>                Traina, "Generic Routing Encapsulation (GRE)",RFC 2784<http://tools.ietf.org/html/rfc2784>,
>>>                March 2000.
>>>
>>
>>>                via IPv4 Clouds",RFC 3056<http://tools.ietf.org/html/rfc3056>, February 2001.
>>>
>>
>> Same as above.
>>
>>>
>>>                Optimization for Mobile IPv6",RFC 4866<http://tools.ietf.org/html/rfc4866>, May 2007.
>>
>>>                Workshop on Routing and Addressing",RFC 4984<http://tools.ietf.org/html/rfc4984>,
>>>                September 2007.
>>>
>>
>>>                draft-ietf-lisp-interworking-02.txt<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02.txt>   (work in progress).
>>>
>>
>>>                draft-ietf-lisp-ms-09.txt<http://tools.ietf.org/html/draft-ietf-lisp-ms-09.txt>   (work in progress).
>>>
>>
>>>                Versioning",draft-ietf-lisp-map-versioning-01.txt<http://tools.ietf.org/html/draft-ietf-lisp-map-versioning-01.txt>   (work
>>>                in progress).
>>>
>>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 30 Oct 2011 23:14:34 +0200

Dino,

> I will add this text modulo the last sentence. I don't understand how ALT plays into this. So I felt it was a random statement.

OK

>   Did you mean LISP relies on a secure mapping database system?

I just wanted to highlight that while LISP does need its mapping system to work correctly, so does the current Internet need BGP to run correctly. So there is no big difference in the security of these two as far as that part goes.

But it is not important. If you don't want to include it, feel free to use the text that you like.

> Schemes are work in progress and hence why we don't want to list them. We had mentioned this before from the Nanog-triggered thread which we moved over to the [email-masked] list.

I agree that we should not mention any schemes. But I do want to add the last sentence, because I think it is a true statement and more importantly, it provides IMO a fair assessment of the potential difficulties.

>>>     management (AKM).BCP 107<http://tools.ietf.org/html/bcp107>   provides guidance in this area.

Grumble. I think it would be better with a text that describes the implications. And I think we could actually do a better job than the security ADs are apparently telling you to do. It is not unheard to have a discuss waiting for us anyway even if some text was agreed, if we haven't done our homework. But I'll let this go in the interest of expediency, and because I happen to believe AKM in this case is an almost complete non-issue. But I do not want to take this approach in the other issues.

> All described in the LISP-MIB, which is still ongoing. I will make sure we put any configuration guidelines in there.

OK

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 30 Oct 2011 23:46:55 +0200

Dino,

>    Instance ID LISP Canonical Address Format:

I now understand the background, thank you for the explanation. But I think the WG still made the wrong call on this.

I would like to play the manager who tells you that the we need to ship your product and this feature still has bugs in it. Lets rip it out and not endanger our release schedule. In other words, I think other people will have the same questions as I did about this part and there is no technical reason why it needs to be here. I don't think the text is harmful by itself, but I predict unnecessary questions. Lets remove it and move on.

>>>        BCP 26<http://tools.ietf.org/html/bcp26>: "Specification Required", "IETF Consensus", "Experimental

The standard model for this text is to include the terms that are used in subsequent text. In any case, the terms above are also outdated after RFC 5226 came out.

I've taken this into account in my next proposed change (see below) and if you use that text you do not need the above text any more.

> Terry needs to respond to this.

I'm not sure if we have seen a response, but I also don't think it is hard to develop the text for this. This one needs to go in, because otherwise we don't know how to manage the name spaces. It is a potential Discuss item from the other ADs or even IANA if the process isn't clear. Here's a strawman text:

IANA should create a registry for managing the new namespaces within the LISP protocol. This registry contains initially the following two new namespaces.

o  New LISP Type values (Section 6.1.1) can be allocated through IETF Review or IESG Approval <xref target="RFC5226"/>. Six values have already been allocated by this specification (Section 6.1.1).

o  New ACT values (Section 6.1.4) can be allocated through IETEF Review or IESG Approval. Four values have already been allocated by this specification (Section 6.1.4).

In addition, the LISP protocol has a number of flag and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags can be taken into use from these fields through IETF Review or IESG Approval, but these need not be managed by IANA.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 30 Oct 2011 22:01:06 -0700

> But it is not important. If you don't want to include it, feel free to use the text that you like.

Okay, I won't include it.

> I agree that we should not mention any schemes. But I do want to add the last sentence, because I think it is a true statement and more importantly, it provides IMO a fair assessment of the potenti…

I added this when I responded to you. Is it not sufficient:

   cache sizing and maintenance is an issue to be kept in mind during
   implementation.  It is a good idea to have instrumentation in place
   to detect thrashing of the cache.  Implementation experimentation
   will be used to determine which cache management strategies work
   best.  In general, it is difficult to defend against cache trashing
   attacks.  It should be noted that an undersized cache in an ITR/PTR
   not only causes adverse affect on the site or region they support,
   but may also cause increased Map-Request load on the mapping system.

> Grumble. I think it would be better with a text that describes the implications. And I think we could actually do a better job than the security ADs are apparently telling you to do. It is not unhe…

The security ADs are very sensitive and particular about this text. Do you really want to fight with them? Let's wait for them to comment if you think this is going to happen. Plus the other ADs aren't terribly happy right now not getting the main spec first. So I don't think we should fuel the fire.

I hope you can understand this.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 30 Oct 2011 22:06:49 -0700

> I would like to play the manager who tells you that the we need to ship your product and this feature still has bugs in it. Lets rip it out and not endanger our release schedule. In other words, I…

That is not what's going on here. How about we have an iPhone that has a Settings configruation for screen size and one of the values is a resolution that is larger than the iPhone screen size? What it means, is that something larger is about to come.

This is an experimental protocol. We are still doing the experiment and the chairs wanted to make it easy for us to experiment with new use-cases, even though out of charter. But they may come into charter in the future.

So let's make sure we don't let the IETF process get the best of us.

> I'm not sure if we have seen a response, but I also don't think it is hard to develop the text for this. This one needs to go in, because otherwise we don't know how to manage the name spaces. It i…

We have not.

I want to wait for Terry to respond.

Dino

---

From: Jari Arkko <[email-masked]>
Date: Mon, 31 Oct 2011 07:38:16 +0200

Dino,

>     but may also cause increased Map-Request load on the mapping system.

Yes, this works well for me.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 30 Oct 2011 23:23:57 -0700

> In addition, the LISP protocol has a number of flag and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags can be taken into use from these fields through IETF R…

So see the enclosed changes to the IANA section. I think it is a good compromise.

Dino

---

From: Terry Manderson <[email-masked]>
Date: Mon, 31 Oct 2011 00:06:39 -0700

Sorry for my Lag,

I had a long weekend of ice-hockey officiating.

On 31/10/11 7:46 AM, "Jari Arkko" <[email-masked]> wrote:

>>> To begin with, I did not understand this definition. I'm trying to
>>> understand where the LCAF draft actually makes the instance ID allocations,
>>> and I can't see it. In addition, the "Null Body Type" string only appears
>>> twice in this and the LCAF draft, and neither occurrence explains what it
>>> is. I think something is missing here.
>> The source-EID in an RLOC-probe may contain a null body encoding. Because
>> there was no data packet that triggered this Map-Request. I will add that to
>> the RLOC-probe section.
>> 
>>> Finally, I do not understand why this section is in -lisp. The string "LISP
>>> Address Type Code" does not appear in the rest of the document AFAICT. The
>>> allocations in the LCAF draft seem to be inside a format defined in that
>>> draft.  Shouldn't the IANA allocations and the creation of the registry be
>>> in that draft as well? This seems particularly important, given that the
>>> list of types in -lisp does not match the list in -lcaf.
>> We (the working group) have decided to put the in-charter values in this
>> draft and keep the other values in the LCAF draft. So that is why values 0
>> and 1 are in this draft. Since instance-ID is part of a VPN use-case, this is
>> why it is the next value assigned in the LCAF draft.
>> 
> I now understand the background, thank you for the explanation. But I think
> the WG still made the wrong call on this.
> 

The important thing was understanding that the header had parts in it which
fell (at the time) out of charter - yet still being as complete as possible
in documenting what we can. It made very little sense to just specify the
Instance ID type codes without pointing to one of the major reasons for
having them in the first place. But not stomping all over the charter and
making sensitive people angry at us for promulgating the LCAF values direct
to an IANA registry without IETF review of the LCAF document.

> I would like to play the manager who tells you that the we need to ship your
> product and this feature still has bugs in it. Lets rip it out and not
> endanger our release schedule. In other words, I think other people will have
> the same questions as I did about this part and there is no technical reason
> why it needs to be here. I don't think the text is harmful by itself, but I
> predict unnecessary questions. Lets remove it and move on.
> 

Perhaps this text helps:

   Instance ID type codes have a range from 0 to 15, of which 0 and 1
   have been allocated.  New Type Codes MUST be allocated consecutively
   starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review or
   IESG Approval.

   Type 0:  Null Body Type

   Type 1:  AFI List Type

Since Instance IDs are in the header format with the use of the I bit
justifies it.

>> 
>>>> 14.  IANA Considerations
>>> This sections makes the right allocations from other, already existing
>>> registries (like UDP port numbers). But it should also define what the
>>> policies are for allocating new values with the various new number spaces
>>> that Lisp introduces:
>>> 
>>> - flags
>>> - type
>>> - reserved
>>> - act
>>> - unused flags
>>> - S

Yes, this needs to be done - sorry I didn't notice it in my review.

For all the namespaces, I'm happy with IETF Review or IESG Approval.

> 
> I'm not sure if we have seen a response, but I also don't think it is hard to
> develop the text for this. This one needs to go in, because otherwise we don't
> know how to manage the name spaces. It is a potential Discuss item from the
> other ADs or even IANA if the process isn't clear. Here's a strawman text:
> 
> IANA should create a registry for managing the new namespaces within the LISP
> protocol. This registry contains initially the following two new namespaces.
> 
> o  New LISP Type values (Section 6.1.1) can be allocated through IETF Review
> or IESG Approval <xref target="RFC5226"/>. Six values have already been
> allocated by this specification (Section 6.1.1).
> 

<comment: specify the values, it makes life easier for many>

These are:
       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Map-Notify:                   4    b'0100'
       LISP Encapsulated Control Message: 8    b'1000'

> o  New ACT values (Section 6.1.4) can be allocated through IETEF Review or
> IESG Approval. Four values have already been allocated by this specification
> (Section 6.1.4).

These are:
      (0) No-Action:  The map-cache is kept alive and no packet
         encapsulation occurs.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

      (3) Drop:  A packet that matches this map-cache entry is dropped.
         An ICMP Unreachable message SHOULD be sent.

> 
> In addition, the LISP protocol has a number of flag and reserved fields, such
> as the LISP header flags field (Section 5.3). New bits for flags can be taken
> into use from these fields through IETF Review or IESG Approval,
> but these need not be managed by IANA.
> 

For binary flags, I agree.

For anything that has more than 2 options/types/sub-types and if it hits the
wire, for interop, I always go looking at what a registry says, to then give
me the right set of RFCs to consider for behaviour.

Or have I missed your meaning Jari?

I would feel much more comfortable with IANA tracking a namespaces than
having them sit untracked in RFCs.

Cheers
Terry

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Oct 2011 11:32:25 +0000

Dino,

>>> This text was created, accepted, and agreed upon from the security ADs. So I dare not to touch it.

I'm not at all sure I agree about the genesis of that text, but it
was the result of a protracted set of exchanges, (starting from
what I thought was worse text:-), so I can understand not wanting
to do that again.

However, you can "dare" if you like - its just text and can no
doubt be improved. In particular, Jari's suggested (2) above I
think (might be wrong since I didn't look) was something I also
wanted during that protracted discussion. So while Jari and I
may disagree as to whether or not AKM is an issue here or not, I
think we do agree that documenting the consequences of not having
AKM would be an improvement.

But, I did agree the current text without that so I'll live
with leaving it as it is I guess if that's what the WG want.

S.