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

[Dino Farinacci <dino at cisco.com>]

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

Thanks.

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

> right?  So, saying that this is the service interface between ITRs,  
> ETRs
> and the mapping database system would seem to be an overstatement.

Why is that?

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

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.

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

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.

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

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

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

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.

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

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