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

From: [email-masked] (Noel Chiappa)
Date: Fri, 25 Sep 2009 17:10:41 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Sep 2009 17:16:37 -0400

I want to be a bit careful here.
For me, the wording on the service interface is more than a bit 
overstated, but as long as we treat it as interim, I'm fine with it.
I suspect that one of the issues driving things is a differing view of 
the service being provided.  But I need to have more discussions with 
various folks before I can defend that proposition.

Joel

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 Sep 2009 18:10:34 -0400

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

Oh, right.  Sorry.  Please ignore my other comment about where the  
reply will be sent, as well...

> But that's something of a guess!

I'm not sure that I agree with setting aside this big block in the  
message to add replay protection later, but that isn't a blocking  
issue for me.  If we are setting aside this field for later use,  
though, it should be labeled "reserved for later use", not "nonce".

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 Sep 2009 18:16:16 -0400

On Sep 25, 2009, at 5:16 PM, Joel M. Halpern wrote:

> I suspect that one of the issues driving things is a differing view  
> of the service being provided.  But I need to have more discussions  
> with various folks before I can defend that proposition.

My issue is not with the question of whether this is a service  
interface or not...

My issue is that it says that this encapsulation is "the service  
interface", as in the only service interface, between the mapping  
system and the xTRs.  However, I think that this encapsulation only  
applies to the Map-Request.  The Map-Register and Map-Reply don't use  
it.  Right?  There is other wording that also implies that the Map- 
Register and Map-Reply will be encapsulated, and I want to confirm  
that they won't.

Margaret