Subject: [lisp] Proposed change to draft-ietf-lisp-05.txt

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Sep 2009 10:01:47 -0700

See the changes proposed for the -05 spec. The changes include:

B.1.  Changes to draft-ietf-lisp-05.txt

    o  Posted October 2009.

    o  Added this Document Change Log appendix.

    o  Added section indicating that encapsulated Map-Requests must use
       destination UDP port 4342.

    o  Don't use AH in Map-Registers.  Put key-id, auth-length, and  
auth-
       data in Map-Register payload.

    o  Added Jari to acknowledgment section.

    o  State the source-EID is set to 0 when using Map-Requests to
       refresh or RLOC-probe.

    o  Make more clear what source-RLOC should be for a Map-Request.

    o  The LISP-CONS authors thought that the Type definitions for CONS
       should be removed from this specification.

Bullets 3 and 4 address tracker items #24 and #2. To focus your review  
I have included the text below, as well as attached diffs.

For #24, here is the main text changed:

----

6.1.7.  Encapsualted Control Message Format

    An Encapsulated Control Message is used as the service interface
    between ITRs, ETRs, and the mapping database system described in
    [LISP-MS].

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      / |                       IPv4 or IPv6  
Header                     |
    OH  |                      (uses RLOC  
addresses)                    |
      \  
|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      / |       Source Port = xxxx      |       Dest Port =  
4342        |
    UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      \ |           UDP Length          |        UDP  
Checksum           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    LH  |Type=8 |                    
Reserved                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      / |                       IPv4 or IPv6  
Header                     |
    IH  |                  (uses RLOC or EID  
addresses)                 |
      \  
|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      / |       Source Port = xxxx      |       Dest Port =  
yyyy        |
    UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      \ |           UDP Length          |        UDP  
Checksum           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    LCM |                      LISP Control  
Message                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

    Packet header descriptions:

    OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
       source and destination header address fields.

    UDP:   The outer UDP header with destination port 4342.  The source
       port is randomly allocated.  The checksum field MUST be non-zero.

    LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
       and what follows is either an IPv4 or IPv6 header as encoded by
       the first 4 bits after the reserved field.

    IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
       addresses in the header address fields.  When a Map-Request is
       encapsulated in this packet format the destination address in  
this
       header is an EID.

    UDP:   The inner UDP header where the port assignments depends on  
the
       control packet being encapsulated.  When the control packet is a
       Map-Request or Map-Register, the source port is randomly assigned
       and the destination port is 4342.  When the control packet is a
       Map-Reply, the source port is 4342 and the destination port is
       assigned from the source port of the invoking Map-Request.  Port
       number 4341 MUST NOT be assigned to either port.  The checksum

    LCM:   The format is one of the control message formats described in
       this section.

----

And for #2, here is the main text changed:

----

6.1.6.  Map-Register Message Format

    The usage details of the Map-Register message can be found in
    specification [LISP-MS].  This section solely defines the message
    format.

    The message is sent in UDP with a destination UDP port of 4342 and a
    randomly selected UDP source port number.

    The Map-Register message format is:

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |Type=3 |P|            Reserved                 | Record  
Count  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |            Key ID             |  Authentication Data  
Length   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        ~                     Authentication  
Data                       ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |                          
Nonce . . .                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |                         . . .  
Nonce                           |
    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    |   |                          Record   
TTL                          |
    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    R   | Locator Count | EID mask-len  | ACT |A|       
Reserved         |
    e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    c   |           Reserved            |            EID- 
AFI            |
    o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    r   |                          EID- 
prefix                           |
    d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    |  /|    Priority   |    Weight     |  M Priority   |   M  
Weight    |
    | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    | o |           Unused Flags      |R|           Loc- 
AFI             |
    | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
    |  \|                              
Locator                           |
    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

    Packet field descriptions:

    Type:   3 (Map-Register)

    P: Set to 1 by an ETR which sends a Map-Register message requesting
       for the Map-Server to proxy Map-Reply.  The Map-Server will send
       non-authoritative Map-Replies on behalf of the ETR.  Details on
       this usage will be provided in a future version of this draft.

    Reserved:  Set to 0 on transmission and ignored on receipt.

    Record Count:  The number of records in this Map-Register  
message.  A
       record is comprised of that portion of the packet labeled  
'Record'
       above and occurs the number of times equal to Record count.

    Key ID:  A configured ID to find the configured Message
       Authentication Code (MAC) algorithm and key value used for the
       authentication function.

    Authentication Data Length:  The length in bytes of the
       Authentication Data field that follows this field.  The length of
       the the Authentication Data field is dependent on the Message
       Authentication Code (MAC) algorithm used.  The length field  
allows
       a device that doesn't know the MAC algorithm to correctly parse
       the packet.

    Authentication Data:  The message digest used from the output of the
       Message Authentication Code (MAC) algorithm.  The entire Map-
       Register payload is authenticated with this field preset to 0.
       After the MAC is computed, it is placed in this field.
       Implementations of this specification MUST include support for
       HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256  
[RFC4634]
       is recommended.

    Nonce:  This 8-byte Nonce field is set to 0 in Map-Register  
messages.

    The definition of the rest of the Map-Register can be found in the
    Map-Reply section.

----

Would like to say thanks for the discussion. I don't know how long the  
review cycle will be for this but the chairs will decide on consensus  
for these changes.

Thanks,
Dino/Dave/Darrel/Vince

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 Sep 2009 15:57:27 -0400

Hi DIno,

Thanks for putting this summary together, it was very helpful to me in  
understanding what you plan to change.

>   between ITRs, ETRs, and the mapping database system described in

If I understood correctly, only the Map-Request would be encapsulated
this way, right?  The Map-Register and Map-Reply packets would not,
right?  So, saying that this is the service interface between ITRs, ETRs
and the mapping database system would seem to be an overstatement.

I thought that the inner UDP destination port would also be 4342, as  
the next
thing up is also a LISP control message.

> Checksum           |

As indicated above, I believe that this particular encapsulation  
diagram will
only be used for Map-Register, so much of this text should be  
reworked.  I
also think it will always have a UDP destination port of 4342, right?

>   LCM:   The format is one of the control message formats described in

Is it worth stating that you can't have an Encapsulated Control Message
inside an Encapsulated Control Message?

[...]
>      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256  

Is it really sufficient to hash only the Map-Register payload?  Or do  
you need to hash (at least some fields of) the protocol headers, as  
well?  I think, for example, that we may return the answer to the  
source RLOC in the outer header, right?  Are there any other fields in  
the outer header that may need to be checked to ensure that the Map- 
Reply is being sent to the right place, or that this Map-Request was  
really sent by who we think it was?

>   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register  

Why is this set to 0?  Wouldn't this still be useful to determine that  
a reply was actually in response to our request?  Why include the  
field in the Map-Register message if it will always be 0?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 26 Sep 2009 21:08:30 -0700

>
> Hi DIno,
>
> Thanks for putting this summary together, it was very helpful to me  
> in understanding what you plan to change.

Thanks.

> this way, right?  The Map-Register and Map-Reply packets would not,

Right.

> and the mapping database system would seem to be an overstatement.

Why is that?

> thing up is also a LISP control message.

I kept it unspecified because a Map-Reply or Map-Register *could* be  
encapsulated as well. At least the packet format could allow it even  
though the text doesn't indicate that anywhere. That is, only a Map- 
Request can be encapsulated and that *is* specified.

> also think it will always have a UDP destination port of 4342, right?

This *could* be a feature. I'd like to keep it there. The code should  
be able to decode any control packet type that is encapsulated.

> inside an Encapsulated Control Message?

No, I don't think so. If it is necessary to have another level of  
indirection, you may want to do so.

We (cisco) have seen many protocols designed where a service provider  
would deploy the protocol and a virtualized user would want to  
implement the same service. So encapsulating control messages that are  
just messages for the underlying LISP may be a useful feature. But I'm  
not willing to specify it at this point.

There is no reason to create a "Map-Request Encapsulated Control  
Message" and then later create another one for say any new control  
packet we introduce (or for Map-Replies or Map-Requests).

> Is it really sufficient to hash only the Map-Register payload?  Or  
> do you need to hash (at least some fields of) the protocol headers,  
> as well?  I think, for example, that we may return the answer to the

What is being authenticated is the EID-prefix data. And if you sent  
different EID-prefixes from different ETRs of the same site to  
different Map-Servers, you could use different keys and therefore  
compute different MACs.

> source RLOC in the outer header, right?  Are there any other fields  
> in the outer header that may need to be checked to ensure that the  
> Map-Reply is being sent to the right place, or that this Map-Request  
> was really sent by who we think it was?

I don't think so.

> Why is this set to 0?  Wouldn't this still be useful to determine  
> that a reply was actually in response to our request?  Why include  
> the field in the Map-Register message if it will always be 0?

Because it is not used. I think I'll remove the nonce from the Map- 
Register. Is that okay with everyone? Since the Map-Register is a one- 
way packet, the map-server can't do anything with it.

> Margaret

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Sep 2009 11:18:33 -0400

Thanks for the reply, Dino.

>> and the mapping database system would seem to be an overstatement.

Because it says that "an Encapsulated Message is used as the service
interface"...  There are several issues with that:

(1) As I think we agree, the interface between the ITR, ETR and mapping
system will involve both encapsulated and unencapsulated messages.  So
encapsulated messages aren't "the service interface"...

(2) A service interface is not (merely) a packet layout.   So, this is  
the
wrong place in the document to claim we are defining the service
interface.  In fact, this document doesn't define the full service  
interface
at all, as the actual service interface is defined in LISP-MS.

How about the following change:

Your Proposed -05:

New:
   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system
   described in [LISP-MS].
>>
>> I thought that the inner UDP destination port would also be 4342,  
>> as the next

Okay.
> This *could* be a feature. I'd like to keep it there. The code  
> should be able to decode any control packet type that is encapsulated.

I am a bit concerned about the interoperability implications here...   
Are we actually requiring that LISP nodes be able to decode any
control message type inside an Encapsulated Control Packet?  If so, I  
don't think that text was included in your edits, is it?  Also, if you  
want to make this generic, why have you limited its scope to the  
mapping system described in [LISP-MS], and why have you indicated that  
it may contain one of three control message types?  At the present  
time, it seems that the text is in an awkward position half-way  
between defining the specific usage of this encapsulation (Map- 
Registers) and making it a generic encapsulation for any control  
message.  I'm not sure which way the WG would prefer to go on this (I  
could go either way), but we should pick one and do that.

This whole discussion has me wondering why the functionality of the  
mapping database system is defined in [LISP-MS] while the associated  
control packets are defined in [LISP].  It seems like this creates  
overlapping content in the two documents, with no strong notion of  
which would be considered normative if they don't match.  Also, it  
makes both documents harder to read, IMO.  Would you consider moving  
the mapping-related control messages to [LISP-MS]?

> Register. Is that okay with everyone? Since the Map-Register is a  
> one-way packet, the map-server can't do anything with it.

I would support removing it.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 27 Sep 2009 10:46:43 -0700

> encapsulated messages aren't "the service interface"...

In the existing documents, that is the way *we* defined it.

> (2) A service interface is not (merely) a packet layout.   So, this  
> is the

That is correct. We reference the LISP-MS document.

So why be so pedantic?

>  packets sent between xTRs and the mapping database system

Fine, I can make that change. But we are splitting hairs IMO.

>> I kept it unspecified because a Map-Reply or Map-Register *could*  
>> be encapsulated as well. At least the packet format could allow it  
>> even though the text doesn't indicate that anywhere. That is, only  
>> a Map-Request can be encapsulated and that *is* specified.
>
> Okay.
> I am a bit concerned about the interoperability implications  
> here...  Are we actually requiring that LISP nodes be able to decode  
> any
> control message type inside an Encapsulated Control Packet?

In the future yes, now, they don't have to. Don't worry, be happy.  ;-)

> If so, I don't think that text was included in your edits, is it?   
> Also, if you want to make this generic, why have you limited its  
> scope to the mapping system described in [LISP-MS], and why have you

Because that is all we have designed so far.

> indicated that it may contain one of three control message types?   
> At the present time, it seems that the text is in an awkward  
> position half-way between defining the specific usage of this  
> encapsulation (Map-Registers) and making it a generic encapsulation  
> for any control message.  I'm not sure which way the WG would prefer  
> to go on this (I could go either way), but we should pick one and do  
> that.

Can we please leave it this way? It is not hurting anything and it  
doesn't narrow the specification we can experiment with new ideas.

> control packets are defined in [LISP].  It seems like this creates

Like I have said many times, we wanted to packet formats in one place  
so insanity wouldn't ensue in the implementer's mind.

> the mapping-related control messages to [LISP-MS]?

We are not overlapping. The main spec says there is a packet format,  
and the MS spec says how to use it. There is a clear demarc.

> I would support removing it.

I will send out another diff tonight with your suggested fix above.

Dino