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.