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

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Margaret Wasserman <mrw at sandstorm.net>

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

Well, a _bit_ of an overstatement, but yes... :-)


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

Interesting question; I don't think so, because all the information in the
mapping entry is contained inside the LISP portion of the Map-Register, and
is therefore protected by the hash. I can't think of any information from the
outer headers that would be used in any way (except the ETRs RLOC, and that
would only be used to kind the correct key anyway).

    > I think, for example, that we may return the answer to the source RLOC
    > in the outer header, right?

Err, what answer? Map-Registers are not acknowledged.

    > 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'm confused. The new authentication stuff only appears in Map-Reqister
messages, not Map-Request/Map-Reply messages, AFAIK.


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

    > Why is this set to 0? ... Why include the field in the Map-Register
    > message if it will always be 0?

Ummm, I think I might be the cause of that - unless it's there because
there's a desire to make all the control packets look similar (i.e. include a
nonce field).

When the issue of replay protection was raised, since replay is generally an
on-path attack, I was trying to add a 'hook' to the Map-Register packet that
would allow us to add replay protection _later_, without changing the packet
format. (I.e. defer adding the _mechanism_ to deal with that attack till
later, since it's an unlikely attack; but at the same time, putting a field
in now would avoid interoperability problems - or using another opcode for a
new format Map-Register - later. I.e. a cheap thing to do now - since we're
chaning the packet format _anyway_ - to avoid a painful change later.) I had
worked out a mechanism using a nonce, so perhaps that's what this is?

But that's something of a guess!

    > Wouldn't this still be useful to determine that a reply was actually in
    > response to our request? 

?? Map-Registers are not acknowledged.

	Noel