Re: [Autoconf] mail formatting (was: I-D Action:draft-bernardos-autoconf-addressing-model-00.txt)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Autoconf] mail formatting (was: I-D Action:draft-bernardos-autoconf-addressing-model-00.txt)
Alex,
I use the Google mail interface (I know, now you can blame me for
trusting Google my mails ;-)
This email is written in plain text. Better now? Otherwise, I can also
try to use Thunderbird, the Mac mail program etc for mails to IETF
lists.
Ulrich
On Wed, Oct 28, 2009 at 2:22 PM, Alexandru Petrescu
<alexandru.petrescu at gmail.com> wrote:
>
> Ulrich Herberg a écrit :
>>
>> Hi Teco,
>>
>> On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <teco at inf-net.nl <mailto:teco at inf-net.nl>> wrote:
>>
>> Hi Ulrich,
>>
>> Few things.
>>
>> Please realize your rich text mails is becoming a mess, when
>> replied with other tools. This troubles the already troubled
>> discussion. I stop cleaning up.
>>
>>
>>
>> I did not realize that. If I just answer like now (without changing the font), is it readable? If not, I can also change to plain text for future mails.
>
> Ulrich - I see your mails are in variable-size font format, including this one. (and not fixed-font like Courrier). Also, I see a strange "|" citation sign instead of the usual ">". This makes me incapable of properly citing your messages.
>
> Now, looking at the source code of your messages it seems that you use MIME and:
>>
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-Transfer-Encoding: quoted-printable
>
> Not using MIME at all would help (although there may be Transfer-Encoding schemes other than quoted-printable which may allow to still use MIME yet not have this problem)
>
> Could you please try to fix this? (I can help) - it should happen via the list, though.
>
> Alex
>
>
>>
>>
>> Then on the small stuff: we are working on MANET stuff, OK?
>>
>>
>> I hope so :-)
>>
>> We have a radio, right?
>>
>>
>> yes
>>
>> We can use this radio for catching background noise, right?
>>
>>
>> yes
>>
>> This is either thermal noise, human made noise, interference, timing,
>> timing of packets received, just to come up with a few.
>>
>>
>> Yes, I am aware that a radio can be good enough as entropy source. The question is: can we _always_ assume that it is good enough (or accessible to the device)? Is there an RFC that claims something like: "All devices that are used in a MANET MUST be able to provide a sufficiently good entropy source". (for whatever meaning of "sufficient")
>>
>> Because, if we don't have that, I am not sure we can rely on good random numbers. Maybe we want to add this somewhere, or we have a common understanding that all devices have a good enough entropy source.
>>
>>
>> Please let me know this does not make sense. Because then, I want
>> to be warned and want to stay far, far away from such devices.
>>
>>
>> And still such devices might exist if we don't exclude their use in MANETs.
>>
>>
>> You were active on MANET and security. Spend some cycles on
>> PRN for small embedded devices with radios? I don't want to push you,
>> but it would help us if you do.
>>
>>
>>
>> For security purposes, evidently the requirements for PRNs are very high. I admit that I am not an expert on PRNs, so I cannot tell you much. I will try to ask our cryptographers in the department, hopefully they can enlighten this issue.
>> To my knowledge, there are sufficiently good PRNs (even for small embedded devices), but they depend on very good entropy sources. So when specifying, say, a security extension to a MANET routing protocol, that document should probably mention some requirements of the entropy source and the PRN.
>>
>>
>> Ulrich
>>
>>
>>
>>
>> Regards, Teco
>>
>>
>>
>>
>>
>> Van: Ulrich Herberg [mailto:ulrich at herberg.name
>> <mailto:ulrich at herberg.name>]
>> Verzonden: woensdag 28 oktober 2009 12:43
>> Aan: Alexandru Petrescu
>> CC: Teco Boot; autoconf at ietf.org <mailto:autoconf at ietf.org>
>> Onderwerp: Re: [Autoconf] I-D
>> Action:draft-bernardos-autoconf-addressing-model-00.txt
>>
>> Alex, Teco,
>> On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu
>> <alexandru.petrescu at gmail.com <mailto:alexandru.petrescu at gmail.com>>
>> wrote:
>> Teco Boot a écrit :
>>
>> [..]
>> The answer is: it depends. ;-) If you have a good random number
>> generator
>> (i.e. using an unambiguous seed), then the collision probability is
>> extremely low. (I let you calculate it using the birthday theorem).
>>
>> Are birthdays random ??
>>
>>
>> Probably not... I can imagine that there are some peeks 9 months after
>> extremely cold and rainy days ;-) I will not dig deeper into this
>> issue :-)
>>
>>
>> However, if you have small embedded devices, without persistent
>> memory, good
>> random number generator, etc., you can have collisions
>> with a much higher probability.
>> Why? It is easy to build a pretty good PRN generator with radio HW.
>> I would say it is much, much, much, much easier than uniqueness
>> guarantee with try and error duplicate detection.
>>
>> I agree. Moreover, there is an RFC talking how to select good entropy
>> sources such that the PRN generator is good.
>>
>> Do you mean RFC 4086? Yes, as you say, but all depends on selecting
>> a good
>> entropy source. The RFC says:
>>
>> "Is there any hope for true, strong, portable randomness in the future?
>> There might be. All that's needed is a physical source of unpredictable
>> numbers."
>>
>> It also says that if no good hardware entropy sources are available,
>> "there
>> are other possibilities. These include system clocks, system or
>> input/output
>> buffers, user/system/hardware/network serial numbers or addresses and
>> timing, and user input. Unfortunately, each of these sources can produce
>> very limited or predictable values under some circumstances."
>>
>> So it really depends on the kind of hardware we are talking about. I
>> could
>> imagine very small sensors without persistent state or other
>> hardware source
>> such as mentioned in the RFC. Using such a device could lead to
>> collisions
>> when calculating random numbers.
>>
>>
>> (small embedded devices, such as sensors, can constitute good sources of
>> randomness when sampling the temperature, for example - that RFC says).
>>
>> yes. But can we guarantee that each MANET router has a good entropy
>> source?
>> Please point me to some reference saying that each device that can
>> be used
>> in a MANET must have a good entropy source.
>>
>> Ulrich
>>
>>
>>
>> Alex
>> Not even
>> mentioning total network meltdowns after a first MANET merge.
>>
>> And I don't have those devices, I want to stay far, far from them.
>> And I don't want to run protocols for it in my MANETs.
>> Please provide refs to equipment that you have in mind. First,
>> I'll check why good PRN can't be supported. If not, I can stay far
>> away from
>> these (also having security in mind).
>>
>> Still waiting on answers on DHCP DUID, key generation etc.
>>
>>
>> Regards, Teco
>> _______________________________________________
>> Autoconf mailing list
>> Autoconf at ietf.org <mailto:Autoconf at ietf.org>
>> https://www.ietf.org/mailman/listinfo/autoconf
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Autoconf mailing list
>> Autoconf at ietf.org
>> https://www.ietf.org/mailman/listinfo/autoconf
>
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.