headers
Abdussalam Baryun | 13 Jul 2012 04:26
Picon

NHDP's Packet and Message

Hi Thomas,

> I agree with Ulrich.
>
>
> Note that this is all about "messages" in as much as NHDP is concerned.
>

It is about securing neighbor discovery, the draft: manet-nhdp-sec-02

>
> 1) NHDP specifies something akin to "an implementation may recognize
> additional reasons for considering a HELLO message invalid for
> processing"; this I-D specifies such an additional reason, by way of a
> TLV in HELLO messages.
>

yes it does in NHDP, but it does not restrict to messages only,
because it uses/understands [RFC5444] packets.

>
> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an
> incoming HELLO message post-demultiplication. Including the ICV
> Message TLV in HELLO messages therefore makes sense.
>

It may own/create the [5444] packet carrying the hello messages

AB
==============
(Continue reading)

Permalink | Reply |
headers
Thomas Heide Clausen | 13 Jul 2012 04:40

Re: NHDP's Packet and Message


On 13 Jul 2012, at 04:26, Abdussalam Baryun <abdussalambaryun <at> gmail.com> wrote:

> Hi Thomas,
> 
>> I agree with Ulrich.
>> 
>> 
>> Note that this is all about "messages" in as much as NHDP is concerned.
>> 
> 
> It is about securing neighbor discovery, the draft: manet-nhdp-sec-02

No. It is about securing a specific neighborhood discovery protocol - a protocol, whose signaling is
carried in RFC5444 _messages_.

>> 1) NHDP specifies something akin to "an implementation may recognize
>> additional reasons for considering a HELLO message invalid for
>> processing"; this I-D specifies such an additional reason, by way of a
>> TLV in HELLO messages.
>> 
> 
> yes it does in NHDP, but it does not restrict to messages only,
> because it uses/understands [RFC5444] packets.

Irrelevant. RFC6130 speaks of reasons for considering messages invalid.

>> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an
>> incoming HELLO message post-demultiplication. Including the ICV
>> Message TLV in HELLO messages therefore makes sense.
(Continue reading)

Permalink | Reply |
headers
Abdussalam Baryun | 13 Jul 2012 12:03
Picon

Re: NHDP's Packet and Message

Hi,

AB>> It is about securing neighbor discovery, the draft: manet-nhdp-sec-02
>
> No. It is about securing a specific neighborhood discovery protocol - a
> protocol, whose signaling is carried in RFC5444 _messages_.
>

NHDP was not designed for specific purpose of one proactive routing,
but for All MANET Routers. I agree that it specifies messages not
packets as Ulrich mentioned before, but there is no MUST in RFC6130
that its signalling MUST be only messages, we need to consider the
specification's requirement language (MUST, SHOULD, MAY,..etc), there
is no restrictions, there is room for update :)

>>> 1) NHDP specifies something akin to "an implementation may recognize
>>> additional reasons for considering a HELLO message invalid for
>>> processing"; this I-D specifies such an additional reason, by way of a
>>> TLV in HELLO messages.
>>>
>>
AB>> yes it does in NHDP, but it does not restrict to messages only,
>> because it uses/understands [RFC5444] packets.
>
> Irrelevant. RFC6130 speaks of reasons for considering messages invalid.
>

Why irrelevant? RFC6130 speaks of using [RFC5444] packets to carry
specified NHDP-messages. yes, also speaks of invalid NHDP-messages
please read:
(Continue reading)

Permalink | Reply |
headers
Thomas Heide Clausen | 13 Jul 2012 12:35

Re: NHDP's Packet and Message


On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote:

> Hi,
> 
> AB>> It is about securing neighbor discovery, the draft: manet-nhdp-sec-02
>> 
>> No. It is about securing a specific neighborhood discovery protocol - a
>> protocol, whose signaling is carried in RFC5444 _messages_.
>> 
> 
> NHDP was not designed for specific purpose of one proactive routing,
> but for All MANET Routers. I agree that it specifies messages not
> packets as Ulrich mentioned before, but there is no MUST in RFC6130
> that its signalling MUST be only messages, we need to consider the
> specification's requirement language (MUST, SHOULD, MAY,..etc), there
> is no restrictions, there is room for update :)

No, that is wrong. RFC6130 specifies the use of RFC5444 messages.

If you want to use smoke-signals, carved potatoes or something else not specified in RFC6130, then you're
simply not using RFC6130.

This has nothing to do with requirements language.

>>>> 1) NHDP specifies something akin to "an implementation may recognize
>>>> additional reasons for considering a HELLO message invalid for
>>>> processing"; this I-D specifies such an additional reason, by way of a
>>>> TLV in HELLO messages.
>>>>
(Continue reading)

Permalink | Reply |
headers
Abdussalam Baryun | 13 Jul 2012 13:02
Picon

Re: NHDP's Packet and Message

Hi Thomas,

> RFC6130 generates RFC5444 messages, which are carried (as are all RFC5444
> messages) in RFC5444 packets.
> A protocol generating something not specified in RFC6130 is not RFC6130.
> I do not know how it can be made more clear.

I agreed from before that RFC6130 not specify packets, that was the
point for the discussing the update, however, I beleive NHDP idea can
be extended, and RFC6130 MAY be updated in future.

 Please note that RFC5444 mentions in page 7: Packets MAY
be unicast or multicast and may use any appropriate transport
protocol or none.

Best regards
Abdussalam
==================================================
On 7/13/12, Thomas Heide Clausen <thomas <at> thomasclausen.org> wrote:
>
> On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote:
>
>> Hi,
>>
>> AB>> It is about securing neighbor discovery, the draft:
>> manet-nhdp-sec-02
>>>
>>> No. It is about securing a specific neighborhood discovery protocol - a
>>> protocol, whose signaling is carried in RFC5444 _messages_.
>>>
(Continue reading)

Permalink | Reply |
headers
Ulrich Herberg | 13 Jul 2012 17:27

Re: NHDP's Packet and Message

I agree with Thomas. What you propose is a layer violation. It's like sticking application payload in an
IPv6 Extension Header or an L2 frame header.

Ulrich

On Jul 13, 2012, at 3:35, Thomas Heide Clausen <thomas <at> thomasclausen.org> wrote:

> 
> On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote:
> 
>> Hi,
>> 
>> AB>> It is about securing neighbor discovery, the draft: manet-nhdp-sec-02
>>> 
>>> No. It is about securing a specific neighborhood discovery protocol - a
>>> protocol, whose signaling is carried in RFC5444 _messages_.
>>> 
>> 
>> NHDP was not designed for specific purpose of one proactive routing,
>> but for All MANET Routers. I agree that it specifies messages not
>> packets as Ulrich mentioned before, but there is no MUST in RFC6130
>> that its signalling MUST be only messages, we need to consider the
>> specification's requirement language (MUST, SHOULD, MAY,..etc), there
>> is no restrictions, there is room for update :)
> 
> No, that is wrong. RFC6130 specifies the use of RFC5444 messages.
> 
> If you want to use smoke-signals, carved potatoes or something else not specified in RFC6130, then you're
simply not using RFC6130.
>
(Continue reading)

Permalink | Reply |
headers
Abdussalam Baryun | 14 Jul 2012 00:05
Picon

Re: NHDP's Packet and Message

Hi Ulrich,

Please note that I don't mind your approach in <draft-nhdp-sec>  (so I
am not against, but abstained), I presented my comments more to
support another participant opinion and showing my preferance, but I
will need to study the matter more further to see how I can use NHDP.
Thanking you,

Regards
Abdussalam Baryun
==================

On 7/13/12, Ulrich Herberg <ulrich <at> herberg.name> wrote:
> I agree with Thomas. What you propose is a layer violation. It's like
> sticking application payload in an IPv6 Extension Header or an L2 frame
> header.
>
> Ulrich
>
> On Jul 13, 2012, at 3:35, Thomas Heide Clausen <thomas <at> thomasclausen.org>
> wrote:
>
>>
>> On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote:
>>
>>> Hi,
>>>
>>> AB>> It is about securing neighbor discovery, the draft:
>>> manet-nhdp-sec-02
>>>>
(Continue reading)

Permalink | Reply |
headers
Abdussalam Baryun | 13 Jul 2012 11:36
Picon

Re: NHDP's Packet and Message

>Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt
>From: Henning Rogge <hrogge at googlemail.com>
>Date: Thu, 12 Jul 2012 21:11:14 +0200
>
> I agree,
>
> packet signatures are a different kind of context. Instead of
> authenticating a message for the rest of the network, they deal with
> neighbor authentication. The packet signature will never be forwarded
> and might even work on a totally different key-scheme.

Please note that NHDP's packets may be used in the control plane with
DLEP or it may be bridged between node neighbors (encapsulated in
frames instead of IP packets), so it does not always need forwarding.

AB

>
> Henning Rogge
>
> On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name>
> wrote:
>> Dear Chris,
>>
>> I agree that we need to provide similar mechanisms as in NHDP-sec for TC
>> messages as well. I don't think that signing the packet is enough, since
>> that does not provide end-to-end security. Instead, I suggest to submit a
>> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages,
>> and
>> how to handle these messages in OLSRv2.
(Continue reading)

Permalink | Reply |
headers
Henning Rogge | 13 Jul 2012 13:41
Picon
Favicon

Re: NHDP's Packet and Message

Am 13.07.2012 11:36, schrieb Abdussalam Baryun:
>> From: Henning Rogge<hrogge at googlemail.com>
>> I agree,
>>
>> packet signatures are a different kind of context. Instead of
>> authenticating a message for the rest of the network, they deal with
>> neighbor authentication. The packet signature will never be forwarded
>> and might even work on a totally different key-scheme.
>
> Please note that NHDP's packets may be used in the control plane with
> DLEP or it may be bridged between node neighbors (encapsulated in
> frames instead of IP packets), so it does not always need forwarding.

NHDP messages will notbe sent over the control plane of DLEP, because 
DLEP keeps control traffic and data-traffic separated and the 
control-plane will be definitely no MANET interface, so you wont use 
NHDP on it.

Henning Rogge

--

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge <at> fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
(Continue reading)

Permalink | Reply |

Gmane