Subject: [mif] Comments on draft-ietf-mif-mpvd-ndp-support

From: Steven Barth <[email-masked]>
Date: Wed, 22 Jul 2015 10:23:13 +0200

Hello everyone,

some probably non-conclusive comments on the NDP-support draft.

3 "However, including a PVD container or identity
   options inside a Router Solicitation (RS) NDP messages is also
   possible (actually, in this way a host can solicit for information
   from a specific provisioning domain)."

This is awkward. Foremost, hosts only send RSs when they change links
and also replies to RS may be multicasted to all hosts on the links
(and often in practice still are).

In any case I don't see the point of adding the container to the RS and / or
maybe the Identity. This is just plain ambiguous.

3 "The PVD container MUST NOT be fragmented i.e., should the
   IPv6 packet be fragmented, the PVD container and the accompanying PVD
   identity MUST both be inside the same fragment."

The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or
MUST every fragment have a PVD Identity or only the first one?

3 S-bit: Could this not just be encoded as "Name Type" = 0?

3 "Name Type": I find it peculiar that the name type is selectable but not
the signature algorithm (at least to my understanding).

3 "Key Hash": Since this doesn't have a length field a client not understanding
the name type cannot interpret anything in the container even if it does not
want to check the signature. I'm not sure if this is intended.

3 "This MAY imply adding
   padding zero octets to the tail of the PVD container option until the
   alignment requirement has been met"

A MAY padding seems awkward and actually ambiguous. (This also applies to
4 to a lesser degree)

4 Is it useful that PVD ID is a separate TLV if a container MUST have exactly 1 in it
and the stand-alone use (e.g. in RS) is probably questionable?

6 Again as for dhcpv6, timestamps may not be ready for checking at the point
where RAs are evaluated since these are essentially bootstrap protocol and
not all devices do have RTCs or unauthenticated NTP server options may be used
to tamper with wallclock settings.

9 RFC 3971 is in informative references but since you use it as source for
your signature algorithm should it not be normative?

Cheers,

Steven

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Jul 2015 04:07:56 -0700

Hi Steve,

Thanks for the review. See my intial comments inline:

> (and often in practice still are).

And what is the issue in that case if all others on the same link see 
what you are asking for?

> maybe the Identity. This is just plain ambiguous.

Could you open more the "plain ambiguous" part? Ambiguous how to 
implement or how/when to use? If you have a better wording in mind I am 
happy to see it & incorporate it.

> MUST every fragment have a PVD Identity or only the first one?

Again, what is ambiguous here? The container must not be fragmented. If 
the ipv6 packet itself is fragmented the container has to be as a whole 
in one of those fragment. If you have a better wording in mind I am 
happy to see it & incorporate it.

> 3 S-bit: Could this not just be encoded as "Name Type" = 0?

It could. The reason why that is not the case now is that we use RFC6487 
name type registry here are currently value 0 is reserved and therefore 
overloading its meaning in this I-D could be a bit risky.

> the signature algorithm (at least to my understanding).

Algorithms that are directly mapped to name types are listed in RFC6487.

> want to check the signature. I'm not sure if this is intended.

Ok. This is a good point. I'll look into this. My earlier assumption was 
that if security is in place and the host does not understand the name 
type -> skip the entire container. But I think we may need to address 
the case where the end host just does not care i.e. "approve exception" 
that is very typical when surfing web and ignoring expired certificates..

> A MAY padding seems awkward and actually ambiguous. (This also applies to

Care to explain more what is ambiguous? You may end up doing padding but 
not in all cases. If you have a better wording in mind I am happy to see 
it & incorporate it.

> and the stand-alone use (e.g. in RS) is probably questionable?

Until the RS piece is resolved a separate option is imho justified.

> to tamper with wallclock settings.

I assume you are now in Section 6?  It says "..some replay protection 
mechanism such as a.. This specification does not define a replay 
protection solution.."

I understand the point that timestamp may not answer the replay 
protection issue but this I-D is not also relying on it either. I am 
happy to remove the "..such as.." part if that is contentious.

> your signature algorithm should it not be normative?

Hmm.. good point. However, we do not want to mandate entire RFC3971 but 
only parts of it. I wonder how to express that in the 
normative/informative references.

- Jouni

>
>
>
>
> Cheers,
>
> Steven
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Steven Barth <[email-masked]>
Date: Thu, 23 Jul 2015 13:40:24 +0200

> And what is the issue in that case if all others on the same link see what you are asking for?
No, what I find awkward is that a multicasted RA may be triggered by that special RS. So one client's
RS now changes RAs for everyone else on the link. Also clients usually do not send RS regularly and rely on multicast RAs. Yes RA servers may behave differently but you should make clear how they should and that shouldn't clash with v6ops / 6man etc.

> Could you open more the "plain ambiguous" part? Ambiguous how to implement or how/when to use? If you have a better wording in mind I am happy to see it & incorporate it.
What is ambiguous is "However, including a PVD container or identity options inside a Router Solicitation (RS) NDP messages is also possible ". What's the point for making both possible or
more specifically what's the point of having the container in the RS at all?

Or another way: how would I request exactly: PVD identity inside container or just top-level identity?

> Again, what is ambiguous here? The container must not be fragmented. If the ipv6 packet itself is fragmented the container has to be as a whole in one of those fragment. If you have a better wording in mind I am happy to see it & incorporate it.
You are saying "MUST NOT be fragmented" this is clear, but then you explain that statement to mean ("i.e.") that only identity must be in the same fragment as the container. The explanation itself is a bit strange as well since the identity is inside the container.

> Care to explain more what is ambiguous? You may end up doing padding but not in all cases. If you have a better wording in mind I am happy to see it & incorporate it.
You are using a normative MAY, to me that means if I feel like it I may pad here but if I won't nothing would break.

> Hmm.. good point. However, we do not want to mandate entire RFC3971 but only parts of it.

Sure, but I must understand at least parts of that RFC to know the signatures work.

Cheers,

Steven

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Jul 2015 06:44:33 -0700

Hi Steve,

7/23/2015, 4:40 AM, Steven Barth kirjoitti:
> RS now changes RAs for everyone else on the link. Also clients usually
> do not send RS regularly and rely on multicast RAs. Yes RA servers may

I do not think we are changing anything or assuming new behavior 
regarding _when_ to send RS. The end host just can add PVD information 
to an RS it would send anyway based on the rules in RFC4861.

I do agree that is it unnecessary for others in a broadcast link to see 
PVD information that was hinted by a specific end host. However, there 
are existing tools to around that. But anyway, I can add more 
clarification on the assumptions we have on the use here.

> behave differently but you should make clear how they should and that
> shouldn't clash with v6ops / 6man etc.

I do not see what is clashing with V6OPS/6MAN. Please clarify.

>> implement or how/when to use? If you have a better wording in mind I
>> am happy to see it & incorporate it.
> What is ambiguous is "However, including a PVD container or identity
> options inside a Router Solicitation (RS) NDP messages is also possible
> ". What's the point for making both possible or

Since the PVD-ID option is like any ND option out there it can be in an 
RS with or without the container. If the end host wants to e.g. sign the 
PVD-ID, then it would use the container.

> container or just top-level identity?

With container Section 3 should be clear enough with that.
Without container, just add the PDV-ID into the RS like any other ND option.

>> Again, what is ambiguous here? The container must not be fragmented.
>> If the ipv6 packet itself is fragmented the container has to be as a
>> whole in one of those fragment. If you have a better wording in mind I
>> am happy to see it & incorporate it.
> You are saying "MUST NOT be fragmented" this is clear, but then you
> explain that statement to mean ("i.e.") that only identity must be in
> the same fragment as the container. The explanation itself is a bit
> strange as well since the identity is inside the container.

The text currently says "the PVD container and the accompanying PVD 
identity MUST both be inside the same fragment."

I find this quite clear what it means. If you have a better way to 
describe this I am happy to see a text proposal and incorporate it.

>> Care to explain more what is ambiguous? You may end up doing padding
>> but not in all cases. If you have a better wording in mind I am happy
>> to see it & incorporate it.
> You are using a normative MAY, to me that means if I feel like it I may
> pad here but if I won't nothing would break.

While there is no such thing as "normative MAY" I agree using RFC2119 
language might not be appropriate here.

You do not need to add padding if the alignment is met it, which 
sometimes can be the case. Anyway, I would reword the sentence as:
   "This may require adding padding zero octets to the end of the PVD
    container option to meet the alignment requirement."

> Sure, but I must understand at least parts of that RFC to know the

Maybe moving the reference to normative part and clarifying in the text 
that only specific sections of that reference are to be used?

- JOuni

---

From: Steven Barth <[email-masked]>
Date: Thu, 23 Jul 2015 16:22:33 +0200

>
> Since the PVD-ID option is like any ND option out there it can be in an RS with or without the container. If the end host wants to e.g. sign the PVD-ID, then it would use the container.

The latter is to my understanding not really mentioned yet. Personally I would not have imagined that this was intended. In any case I do not see the point in allowing both behaviors (with and without container). Aside my doubts in general about your use of RSs, I think you should decide that whether you want these signed requests then require that the PVD-ID must always be inside a container otherwise only allow them to be on top-level. Allowing both doesn't really give you anything aside unnecessarily bloating implementations.

>
> The text currently says "the PVD container and the accompanying PVD identity MUST both be inside the same fragment."
>
> I find this quite clear what it means. If you have a better way to describe this I am happy to see a text proposal and incorporate it.
Both parts of the sentence make sense to me but not in the "i.e."-combination.
The MUST NOT be fragmented parts sounds to me as if the whole container must not be fragmented but in the "i.e." you only talk about ID but not other encaps'ed options which is what confused me.

Also what do you mean by fragmentation in the first place? IPv6-level fragmentation? If yes, (again aside ND and fragmentation issues in general) there should be an explanation for the MUST here since at least to me its not obvious.

Cheers,

Steven

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Jul 2015 08:07:56 -0700

Steven,

> The latter is to my understanding not really mentioned yet. Personally I would not have imagined that this was intended. In any case I do not see the point in allowing both behaviors (with and with…

Fair enough.. I'll put some more clarifications there for reasons to use 
or not to use container.

> Also what do you mean by fragmentation in the first place? IPv6-level fragmentation? If yes, (again aside ND and fragmentation issues in general) there should be an explanation for the MUST here si…

The text says "should the IPv6 packet be fragmented,.." which imho is 
rather clear it means IPv6 level fragmentation.

Now that the intent should be clear could you propose text that makes 
sense to you? Just to avoid having the same discussion again when the 
next version is out ;)

- Jouni

---

From: Steven Barth <[email-masked]>
Date: Fri, 24 Jul 2015 07:00:03 +0200

>
> The text says "should the IPv6 packet be fragmented,.." which imho is rather clear it means IPv6 level fragmentation.

It is indeed, I feel rather that the intention for your MUST is not obvious.
To me I would either expect all fragmented ND packets to be dropped (esp. multicast), only some to be dropped but the packet to be discarded as a whole because of that, or the whole packet to be correctly reassembled. In all these cases I don't get the intention of your requirement.

Beside that I think this requirement is a layer violation here and would require a very good justification (aside trying to work-around some broken host implementations) since it significantly increases the implementation complexity of the RA server (at least in case your RAs are getting big).

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 24 Jul 2015 05:30:13 -0700

Steven,

> It is indeed, I feel rather that the intention for your MUST is not obvious.

You mean having all options that belong to one PDV being inside one 
fragment?

> To me I would either expect all fragmented ND packets to be dropped (esp. multicast), only some to be dropped but the packet to be discarded as a whole because of that, or the whole packet to be correctly reassembled.

I do not understand what your "expactation" and the above sentence has 
to do with the text in the draft. Actually, I do not understand what the 
above sentence tries to say.

> In all these cases I don't get the intention of your requirement.

Trying to keep the container as a whole if someone for some reason wants 
to peek into it before reassembly.. but it is not a sticking point for 
the draft. SHOULD would be ok, even removing the whole fragmentation 
text could be ok.

> Beside that I think this requirement is a layer violation here and would require a very good justification (aside trying to work-around some broken host implementations) since it significantly incr…

I don't understand the claim for layer violation.. the implementation 
complexity annoynace I understand.

- Jouni