On 11/2/16 9:02 AM, Luigi Iannone wrote:
Hi Fabio,
I went through the last version of the document.
I still think that in a few place SHOULD should be replaced by MUST.
But it is just my point of view. You can leave SHOULD.
There are just few residual issues:
- Introduction: The second sentence is not coherent with the first
one. The concept of EID-to-RLOC mappings as not been introduced so
starting the sentence with “These EID-to-RLOC mapping s…” is pretty
unclear. I would suggest you add another sentence.
- Section 7 IANA Considerations: For almost all of the registries the
value “0” has a special meaning that this demo is defining, hence the
“defined in” field should state “this memo”
- - Section 7 IANA Considerations: The section is not yet 5226
compliant. More specifically, you have to state for each registry how
new values are allocated (e.g. FCFS, expert review, etc..)
Thanks Luigi,
do you have any suggestion for the best policy to use for allocation of
unassigned values?
It seems to me that given the experimental nature of the draft, for all
of the registries created, we could require that 'unassigned values are
to be assigned according to the "Specification Required" policy defined
in [RFC5226].'
Fabio
Check again the nits:
Checking nits according tohttp://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 10 instances of lines with non-RFC6890-compliant IPv4
addresses in the document. If these are example addresses, they should
be changed.
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'RFC4634' is mentioned on line 840, but not defined
** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)
The above nits reminds me of another issue that the IESG will
certainly raise: can we have all the examples in IPv6 only?
The latest directives are that either you use both v4 and v6 or
v6-only, but NOT v4-only.
Thanks
ciao
L.
On 27 Oct 2016, at 23:48, Fabio Maino <[email protected]
<mailto:[email protected]>> wrote:
Luigi,
I agree with all the comments.
The document attached should reflect all your suggestions.
A few notes below, just to explicitly ack the changes you suggested.
On 10/26/16 2:13 AM, Luigi Iannone wrote:
Hi Fabio,
Yes we are converging, very few points are left.
Inline are my comments, I snipped everything that we already agreed
up on.
L.
On 26 Oct 2016, at 02:14, Fabio Maino <[email protected]
<mailto:[email protected]>> wrote:
[snip]
Also, what is the MS stubbornly insists in using an algorithm that
the ITR does not support?
The MS might not have alternatives, as it might only support one
algorithm.
Sure
The question is: can we have situations in which MS replies always
with the same algorithm (because has no alternatives) and the ITR is
never able to understand that reply (because has no alternatives).
From my understanding this can happen, right?
LISP-SEC has no way to prevent it, right?
What is needed is a policy like “ITR tries using all of the
algorithm it supports and then gives up”, right?
If the answer to those questions is yes, then IMO this should be
spelled out somewhere.
got it. Agreed.
[snip]
The KDF ID field, specifies the suggested key derivation function to
be used by the Map-Server to derive the MS-OTK.
What happens if the MS will choose a KDF ID not supported by the
ITR?
Can you clarify how to solve this situation or explain why this
will never happen?
This is described a few paragraphs below:
"
If the KDF ID in the Map-Reply does not match the
KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
Reply and send, at the first opportunity it needs to, a new Map-
Request with a different KDF ID, according to ITR's...
"
This does not guarantee that the MS will reply with something the
ITR understands….
For some local ITR's policy it may not be guaranteed. It's a
balance between reachability and security that the ITR will have to
choose.
I am not sure I understand your reply.
My point was the same as above: what if MS and ITR are not able to talk?
ok. So this is addressed by the same fix used for the previous
comment. I'll specify that the ITR will stop re-sending map-requests
once all HMAC IDs supported by the ITR have been attempted.
The EID-AD length is set to 4 bytes, since the Authentication Data
does not contain EID-prefix Authentication Data, and the EID-AD
contains only the KDF ID field.
In response to an encapsulated Map-Request that has the S-bit set, an
ITR MUST receive a Map-Reply with the S-bit set, that includes an
EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the
ITR MUST discard it. In response to an encapsulated Map-Request with
S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
the ITR SHOULD discard the Map-Reply if the S-bit is set.
Why a “SHOULD”? If the Map-Request has S-bit=0 it mean that
there is no AD, hence no OTK, how can the ITR decrypt the reply?????
It MUST discard…..
If S-bit = 0 there's no Authentication Data. The Map-reply is in
clear, and can be read.
I am not sure you understood my point.
You send a Map-Request with S=0, hence unenbcrypted. How can you
possible receive a Map-Reply with S=1?
How is it encrypted if the ITR did not provide any OTK?
Misconfiguration, bugs? I was just trying to enumerate the
behaviors of the ITR. There's probably something wrong, and the
map-reply should be discarded. Still the mapping is readable, so an
ITR favoring reachability may decide to use the mapping.
Oh… I may see the misunderstanding. You are saying that the bit is
set in the Map-Reply, but actually the content is not encrypted,
right? SO the ITR can decide whether or not to use it.
Is that right?
right.
[snip]
I think “log message" is too much implementation specific.
If there is a notification, and how this notification is done,
is implementation specific IMHO.
ok. Same as above.
The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache
because it matches the second EID-prefix contained in the EID-AD.
The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
is not included in any of the EID-ADs signed by the Map-Server. A
log message is issued.
I think “log message" is too much implementation specific.
If there is a notification, and how this notification is done,
is implementation specific IMHO.
ok. Same as above
In this last example the ETR is trying to
over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
only 1.2.3.0/24, hence the EID-record is discarded.
Reading the example I am not sure I would follow this behaviour.
Only 1 record out of 3 is valid so why should I actually trust
the ETR instead of throwing everything away?
Can you explain ???
The other two records are validated by the MS, so there is no
reason to throw those away.
Yes, but the ETR is still trying to cheat on the third one….
So the ETR may be compromised, why should I send traffic to him???
ITR has flagged the security exception with the log entry, and some
local ITR policy will decide what to do (including stop
encapsulating to the ETR, if that's what is specified by the
policy). At the LISP level LISP-SEC has done its job: verified
mapping goes into the map-cache, overclaimed mapping is dropped.
This is not what the above text states. The text states that the
valid EID-record is stored in the map-cache.
To be consistent with your reply you should change and state that
the EID-record is eligible to be used by the ITR.
got it. I changed 'stored into the map-cache' with 'eligible to be
used by the ITR'. For consistency I have used similar language for
the other two cases (rather than not processed).
BTW to be consistent with other LISP document you should use "LISP
Cache” instead of “map-cache” (in the whole document).
ok. With the change above we don't use the word map-cache anymore in
the document. So this is addresses as well.
Thanks!
Fabio
[snip]
<Diff_ draft-ietf-lisp-sec-11.txt -
draft-ietf-lisp-sec-12b.txt.html><draft-ietf-lisp-sec-12b.txt>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
