On Mon, 19 Aug 2013, Ole Troan wrote:
In working group last call:
draft-ietf-6man-oversized-header-chain-04 (ending August 27th)
I have read this document and found no problem with it, and I support its
progression.
draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd)
--------------------------------------------------------------------
NIT:
F():
A pseudorandom function (PRF) that is not computable from the
outside (without knowledge of the secret key), which should
produce an output of at least 64 bits.The PRF could be
implemented as a cryptographic hash of the concatenation of
each of the function parameters.
Missing space in the middle line.
-------------------------------------------------------------------
secret_key:
A secret key that is not known by the attacker. The secret
key MUST be initialized at operating system installation time
to a pseudo-random number (see [RFC4086] for randomness
requirements for security). An implementation MAY provide the
means for the the system administrator to change or display
the secret key.
I think the text here should be that i MUST be initialized when the
functionality is enabled (or equivalent). I haven't re-installed my
operating system for 8 years, I have just upgraded it. Also, this
functionality might be a later add-on to an existing version of the
operating system, and the functionality might be an add-on to the
connection manager, completely independent of the operating system.
-------------------------------------------------------------------
There are numerous references to DAD. Isn't DAD attacks handled in other
documents that can be referenced, does this document really need to
outline this behaviour, perhaps even in conflict with other documents? I
don't remember where I read about this though, perhaps someone else knows?
It was discussed in SAVI anyway.
I think it would be good to reference SAVI-WG documents on first-hop
security instead of writing new text on the subject. People seem to like
SEND, but I see send as hard to deploy in most scenarios because one
entity doesn't control both router and device. I prefer the network
protecting using filtering instead of trying to cryptographically assure
that the RAs seen is from the router.
http://datatracker.ietf.org/wg/savi/ RFC 6620 would be one document to
reference in this case.
Network_ID mentions SSID. What if I have an ethernet Interface and I move
my computer around, should it identify a new set of /64 network address
and/or gateway MAC address as a new network as well? I think some text on
this would be good guidance for implementors.
--
Mikael Abrahamsson email: swm...@swm.pp.se
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
