Subject: [mif] MIF draft issues

From: Steven Barth <[email-masked]>
Date: Wed, 4 Nov 2015 13:43:07 +0100

As requested in the DT meeting, here is a summary of the issues and from
my reviews of the 3 "core drafts".

To be honest I'm totally put off by the lack of responsiveness from all
draft authors and will probably not do any more reviews here if there
isn't a significant improvement on this matter.

Cheers,

Steven

*** Conceptual (apply to all 3) ***

1. Lack of metadata
Neither draft defines any kind of metadata or seems to consider any
addition of it. Currently only opaque identifiers are used which must be
previously acquired via other means to understand a PVD, i.e. it is not
possible to convey:
* if the PVD offers intenet access or not
* if use of the PVD is metered or not
* general constraints of using the PVD
* even a human readable name

*** mpvd-id ***

It is not clear why this multitude of types is needed. If it is kept
there should be some guidance on why it is not possible to simply use
one unique type format like FQDN or a reasonably small unique
fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD
owner followed by a small localy significant ID.

1+3. "Any source that does not provide either guaranteed or
probabilistic uniqueness is probably not a good candidate for
identifying provisioning domains." - I don't see how type "UTF-8 string"
fits this definition.

Abstract: the abstract claims the document "describes several methods of
generating identification information for provisioning them". However I
can't find that anywhere, I can only find a TLV-definition.

3: It is unclear what the actual format for the specified id-types is,
at least for some of them, e.g. is the UUID in binary format or
string-representation? FQDN is unclear as well, RFC1035 never mentions
this abbreviation and also given it would be clear it still doesn't say
if it uses the textual or label sequence representation?

4: Security Considerations do not apply at all. Your abstract says:
"This document describes several methods of generating
identification information for provisioning them and a format for
carrying such identification in configuration protocols."
however your security considerations explain attacks on (2 specific)
protocols the TLV might be used in instead of security implications of
using different types of identifiers e.g. like security considerations
of UUID in RFC4122

5: IANA Section lacks policy for further allocations (see RFC5226)

3: "The configuration protocol used and its extensions are
meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support]
[I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse.

*** ndp-support ***

1. It is unclear what to do with enclosed TLVs

Section 5 defines what TLVs can and cannot be enclosed, however it is
unclear how any enclosed TLVs are treated or whether and in what respect
they are treated differently from if they would occur on the top-level.
To be more concrete, what should a PVD-aware node do if it receives e.g.
a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then
use it at will as defined in RFC 4862 ('Initially, an address is
"preferred", meaning that its use in arbitrary communication is
unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the
point of the exercise of the container? Supposedly similar things could
be said about RDNSS, DNS-Search or other enclosed PVD types as well.

2. The solicitation mechanism using RS seems underspecified.

It is not mentioned how the router should react to receiving a PVD CO /
ID (e.g., include PVD-information only in the specific reply, or in all
subsequent unsolicited RAs for an undefined period of time, ...). This
is unclear esp. considering that hosts do not send RS regularly and the
draft does not place an such requirements on hosts. The draft also does.

Also it is unclear what the semantic difference between an RS with a
PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if
there is none, what the reasoning for this redundancy is.

3. Hosts not supporting security cannot use secured PVD information.

The length of the fields "Key Hash" and "Digital Signature" depend on
the meaning of the field "Name Type" and are thus unskippable in general.

4. Signature calculation is unclear.

The signature generation defined in RFC 3971 includes several other
components (e.g. a CGA message type tag, a kind of pseudoheader, etc.)
besides the actual NDP message being signed. It is unclear is your
signature mechanism uses the same header fields or if the intention was
just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO.

5. Mandatory to implement security seems outdated.

The use of SHA-1 as only mandatory hash for key identification and as
only defined hash for signatures seems a bit outdated these days
especially in the light of recent advancements in its cryptanalysis.

This seems especially problematic since there does not seem to be a way
to signal the use of a different signature algorithm.

6. Replay Protection seems not adequately addressed.

No specific mechanism is defined. It is suggested to use either
timestamps or a nonce of an undefined format. However nonces do not seem
particularly effective for unsolicited RAs and timestamps rely on
accurate wall-clocks on both server and client side which is not mentioned.
Also the suggested use of SeND would not provide replay protection for
the PVD_CO however only for the whole RA being secured.

7. It is unclear how TLVs are enclosed in the PVD_CO

The PVD_CO definition does not mention where TLVs are enclosed, i.e.,
before or after either Header, Key Hash, Digital Signature, Padding etc.

8. General Design is very space-intensive.

Notably for support of both PVD-aware and unaware nodes enclosed TLVs
need to occur both inside and outside of the container. Also if some
enclosed TLVs apply to multiple PVDs they will be duplicated in
different containers.

In addition in-band security and signatures can easily increase the size
of the overall messages very much, especially since RSA is the only
defined scheme.

9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ a
   provisioning domain."

*** dhcp-support ***

0. This draft cannot be freely implemented in open source software.

1. It is unclear what to do with enclosed TLVs

The reasoning is similar to the NDP TLVs in the other draft: The draft
defines what TLVs can be enclosed but not how the enclosing affects the
meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still
generally applicable for all purposes and if not how is the meaning
changed specifically?

This is especially problematic since the draft does not disallow any
TLVs from being inside the container, see also 2.

2. It is unclear how this draft interacts with the Identity Association
state machines defined in RFC3315

i.e. how are IAs and addresses and prefixes actually enclosed here. The
draft needs to specify clearly what happens to identity associations /
address assignments and how they are associated to PVDs especially
taking into account the possibility of having multiple IAs (e.g. IA_NA
and IA_PD) or addresses from different PVDs in the same IA. See also 3.

3. It is unclear where the PVD container option can occur.

Is it restricted to only occur on the top-level or can it occur also
inside other containers (e.g. Identity Associations), if the latter is
true, how does it affect what options can be enclosed in it.

4. Signature calculation is unclear.

The signature generation defined in RFC 3971 includes several other
components (e.g. a CGA message type tag, a kind of pseudoheader, etc.)
besides the actual NDP message being signed. It is unclear if your
signature mechanism uses the same header fields or if the intention was
just to use a plain RSASSA-PKCS1-v1_5 over the PVD container.

5. Mandatory to implement security seems outdated.

The use of SHA-1 as only mandatory hash for key identification and as
only defined hash for signatures seems a bit outdated these days
especially in the light of recent advancements in its cryptanalysis.

This seems especially problematic since there does not seem to be a way
to signal the use of a different signature algorithm.

6. Replay Protection seems not adequately addressed.

No specific mechanism is defined. It is suggested to use either
timestamps or a nonce of an undefined format.
Also the suggested use of DHCPv6 AUTH would not provide replay
protection for the PVD container but for the whole DHCPv6 message being
secured.

7. Contradicting requirements language
#1: "The PVD container option SHOULD contain at most one (i.e. zero or
one) OPTION_PVD_AUTH."
#2: "If present, the OPTION_PVD_AUTH option MUST be the last option
inside the OPTION_PVD option."
#1 implies I could choose to send more than one OPTION_PVD_AUTH (by not
following the SOHULD) however #2 implies there can only be 0 or 1.

8. Missing normative reference to RFC 3971 (see Section 5).

9. Client and Server Behavior inconsistent
Section 7.1 only instructs client to send an ORO in SOLICIT messages,
however in Section 7.3. servers expect it to be sent (only?) in request
messages.

10. Security concept seems mostly redundant
Since addresses or prefixes are expected to be part of most PVD
containers, DHCPv6 servers need to modify PVD containers in nearly all
cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options).
Therefore - aside for very special cases - the DHCPv6 server would need
the private key for signing in any case so plain DHCPv6 authentication
could be used in the first place.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Nov 2015 14:25:56 +0000

Hi Steven,
Thanks for your review. I will create an issue tracker to keep track of each issue you raised. There are some decisions the WG needs to make to proceed further with some of the changes required and I hope we can get some direction during and after this Friday's session.

Thanks
Suresh

-----Original Message-----
From: Steven Barth [[email-masked]]
Received: Wednesday, 04 Nov 2015, 9:43PM
To: [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: [mif] MIF draft issues

Cheers,

Steven

1. Lack of metadata

*** mpvd-id ***

*** ndp-support ***

*** dhcp-support ***

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

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 5 Nov 2015 12:45:36 -0800

Steven,

Thanks for the comments. See inline.

> To be honest I'm totally put off by the lack of responsiveness from all

Huh?? Anyway, I'll be unresponsive till "ndp-support" part of this mail.

> 1. It is unclear what to do with enclosed TLVs

Explain what you mean by TLV in the context of this draft? This 
word/acronym is not used in the draft.

> be said about RDNSS, DNS-Search or other enclosed PVD types as well.

I would advice to read RFC7556 Section 5. This draft mainly concerns the 
transport of the PVD related configuration information.

> is unclear esp. considering that hosts do not send RS regularly and the

    ..
    with IPv6 RA messages.  However, if a host wants to solicit
    information for a specific provisioning domain it can include the PVD
    identity option into an RS message ..

So it is a hint to a router that someone is interested in a specific 
PVD. I do not think we need to define the implementation details on this 
part further. The router is free to react to the hint as it wishes.

> draft does not place an such requirements on hosts. The draft also does.

The draft also does what?

> there is none, what the reasoning for this redundancy is.

                                                       ...include the PVD
    identity option into an RS message and use the PVD container to sign
    the PVD identity option.

So, the difference should be clear. If you want to sign the idenitity -> 
put it inside PVD_CO with S=1.

> the meaning of the field "Name Type" and are thus unskippable in general.

Hmm seems I missed this from previous comments. If one does not 
understand the used security -> skip the PVD_CO. I'll add this 
clarification.

> just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO.

Fair point. I will clarify.

> 6. Replay Protection seems not adequately addressed.

    ...
    information.  This specification does not define a replay protection
    solution.  Rather it is assumed that if replay protection is...

> the PVD_CO however only for the whole RA being secured.

And replay protecting whole RA would be somehow worse than just 
protecting PVD_CO?

> 7. It is unclear how TLVs are enclosed in the PVD_CO

TLV?

> before or after either Header, Key Hash, Digital Signature, Padding etc.

    The PVD container option (PVD_CO) is used to mark the start of the
    configuration options that belong to the explicitly identified
    provisioning domain.  The PVD container option MUST encapsulate
    ...

Also, there is no "place" for other NDP options inside PVD_CO. For 
clarity refer Appendix A.

> enclosed TLVs apply to multiple PVDs they will be duplicated in

Yes. An unfortunate side effect.

> of the overall messages very much, especially since RSA is the only

Yes. An unfotunate side effect. We are open for more compact solutions.

> 9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ a

Ack. Will fix.

- jouni

---

From: Steven Barth <[email-masked]>
Date: Thu, 5 Nov 2015 23:18:06 +0100

>> *** ndp-support *** >> >> 1. It is unclear what to do with enclosed TLVs > > Explain what
you mean by TLV in the context of this draft? This > word/acronym is not
used in the draft.

Well, ICMPv6 option.

> >> Section 5 defines what TLVs can and cannot be enclosed, however it >>
is unclear how any enclosed TLVs are treated or whether and in what >>
respect they are treated differently from if they would occur on >> the
top-level. To be more concrete, what should a PVD-aware node do >> if it
receives e.g. a PIO with A=1 inside a PVD_CO? Assign an >> address,
perform DAD and then use it at will as defined in RFC 4862 >>
('Initially, an address is "preferred", meaning that its use in >>
arbitrary communication is unrestricted.'). If all PVD SLAAC >>
addresses are unrestricted what is the point of the exercise of the >>
container? Supposedly similar things could be said about RDNSS, >>
DNS-Search or other enclosed PVD types as well. > > I would advice to
read RFC7556 Section 5. This draft mainly concerns > the transport of
the PVD related configuration information.

I know that RFC. It is mentioned once in the intro of your draft, but that
doesn't really help here. Anyway even if there would be a proper
reference to Section 5 here: I guess your intention is that all the TLVs
inside the container only "apply" to that PVD for some obscure definition
of apply. As someone who has implemented one or two RFCs, I think that
is much too vague to result in anything remotely interoperable.

Let's simply say I get a RFC 4191 RIO. Now quoting that RFC
"Then as the host processes Route Information Options in the Router
Advertisement message body, it updates its routing table for each such
option."

Now what happens if that thing is in a PVD_CO? I still update my routing
table? I suddenly need one routing table per PVD? (Note RFC 7556
doesn't explain routing anywhere).

The same is true for most RA options that could possibly be enclosed.

> >> >> 2. The solicitation mechanism using RS seems underspecified. >> >>
It is not mentioned how the router should react to receiving a PVD >> CO
/ ID (e.g., include PVD-information only in the specific reply, >> or in
all subsequent unsolicited RAs for an undefined period of >> time, ...).
This is unclear esp. considering that hosts do not send >> RS regularly
and the > > .. with IPv6 RA messages.  However, if a host wants to
solicit > information for a specific provisioning domain it can include
the > PVD identity option into an RS message .. > > So it is a hint to a
router that someone is interested in a specific > PVD. I do not think we
need to define the implementation details on > this part further. The
router is free to react to the hint as it > wishes.
Okay, so as a host I can send an RS with PVD IDs in it, but since it is
unspecified I do not know if or how the router would react. Your draft
also doesn't mandate for hosts when or when not to solicit other than
"when it wants" so the router can make no assumptions as well.

So since there is no defined state machine or similar this "mechanism"
is there to... provide un-interoperability? I mean clearly since there are
no requirements here I can only use that if I control both the router
and the client, e.g. for piggibagging obscure proprietary behavior into it.

>> Also it is unclear what the semantic difference between an RS with >> a PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and
>> if there is none, what the reasoning for this redundancy is. > >
...include the PVD identity option into an RS message and use the PVD >
container to sign the PVD identity option. > > So, the difference should
be clear. If you want to sign the idenitity > -> put it inside PVD_CO
with S=1.
Please reread my paragraph above, it is unclear what the difference is
between a top-level PVD_ID and a PVD_CO with S=0 so an unsigned
container in an RS and / or why both seem to be allowed.

>> 3. Hosts not supporting security cannot use secured PVD >> information. >> >> The length of the fields "Key Hash" and "Digital
Signature" depend >> on the meaning of the field "Name Type" and are
thus unskippable in >> general. > > Hmm seems I missed this from
previous comments. If one does not > understand the used security ->
skip the PVD_CO. I'll add this > clarification.
Okay, so the intention is basically that if the router signs a PVD_CO,
hosts that do not support authentication cannot use the PVD
information even if they don't care about the signature.

I do not particularly like that, but if that was your intention please
write it out in the draft.

>> 6. Replay Protection seems not adequately addressed. > > ... information.  This specification does not define a replay >
protection solution.  Rather it is assumed that if replay protection >
is... > >> No specific mechanism is defined. It is suggested to use
either >> timestamps or a nonce of an undefined format. However nonces
do not >> seem particularly effective for unsolicited RAs and timestamps
rely >> on accurate wall-clocks on both server and client side which is
not >> mentioned. Also the suggested use of SeND would not provide
replay >> protection for the PVD_CO however only for the whole RA being
>> secured. > > And replay protecting whole RA would be somehow worse
than just > protecting PVD_CO?
Well the scope is different, what it tells me is that the RA wasn't
replayed.
However the one authenticating the RA could have "sniffed" a foreign PVD
container somewhere and just inserted it into its RA. The result is, you
have a known-unreplayed RA from person A with a replayed PVD_CO
of person B.

>> 7. It is unclear how TLVs are enclosed in the PVD_CO > > TLV? I apologize, ICMPv6 options...

> >> The PVD_CO definition does not mention where TLVs are enclosed, >>
i.e., before or after either Header, Key Hash, Digital Signature, >>
Padding etc. > > The PVD container option (PVD_CO) is used to mark the
start of the > configuration options that belong to the explicitly
identified > provisioning domain.  The PVD container option MUST
encapsulate ...
Okay so if it "marks the start" then the intention is all options are put
on the top-level? But how does that "encapsulate options?"
My main problem is that your PVD_CO seems to be defined as a
"closed" option (in the diagram, which seems to be the source for the
on-the-wire-encoding) without any variable length fields anywhere so
it is unknown where and how someone could "encapsulate" options
into it, which btw. should be explained somewhere what you mean
by that term exactly.

> Also, there is no "place" for other NDP options inside PVD_CO. For > clarity refer Appendix A.
>From the example in your Appendix it seems to be that there is an
undefined variable field at the end of your PVD_CO where options
are just dumped in. If that is the intention, then please specify that.

> >> 8. General Design is very space-intensive. >> >> Notably for support
of both PVD-aware and unaware nodes enclosed >> TLVs need to occur both
inside and outside of the container. Also >> if some enclosed TLVs apply
to multiple PVDs they will be >> duplicated in different containers. > >
Yes. An unfortunate side effect. I guess this should be noted in an
Applicability section.

>> In addition in-band security and signatures can easily increase the >> size of the overall messages very much, especially since RSA is the
>> only defined scheme. > > Yes. An unfotunate side effect. We are open
for more compact > solutions.
Well obvious choices are e.g. to use EdDSA.

Also there should be an applicability section somewhere that deals with
this. Say I have 2 different authenticated PVDs that are secured
with a 4096-bit RSA key and want to use SeND on top of that (or 3
PVD_COs with SeND) then even the PVD_CO "headers" might exceed
my MTU. Guidance on how to avoid that is missing.

---

From: Steven Barth <[email-masked]>
Date: Thu, 5 Nov 2015 23:32:28 +0100

Sorry resending, message got garbled.

Well, ICMPv6 option.

> I would advice to read RFC7556 Section 5. This draft mainly concerns
> the transport of the PVD related configuration information.

> PVD. I do not think we need to define the implementation details on
> this part further. The router is free to react to the hint as it wishes.

> So, the difference should be clear. If you want to sign the idenitity
> -> put it inside PVD_CO with S=1.
>

>    solution.  Rather it is assumed that if replay protection is...
Well, what's the point of specifying this authentication then if you
leave it open to attacks?

Well the scope is different, what it tells me is that the RA wasn't
replayed. However the one authenticating the RA could have "sniffed"
a foreign PVD container somewhere and just inserted it into its RA.
The result is, you have a known-unreplayed RA from person A with a
replayed PVD_CO of person B.

>> 7. It is unclear how TLVs are enclosed in the PVD_CO
ICMPv6 option

> Yes. An unfortunate side effect.

I guess this should be noted in an
Applicability section.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 17 Nov 2015 09:53:20 -0800

Thanks for resending -  that was needed ;) I have finally ended my 
marathon travels and will get back to these comments asap.

- Jouni