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

[Margaret Wasserman <mrw at sandstorm.net>]

Hi DIno,

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

A have a few questions/comments about the proposed changes:

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

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.

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

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

>     \ |           UDP Length          |        UDP  
> Checksum           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>   LCM |                      LISP Control  
> Message                     |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>
>   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

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
>      this section.

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

[...]
>   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.

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

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