RE: 6MAN Agenda for IETF86

"Hosnieh Rafiee" <ietf@rozanak.com> Tue, 05 March 2013 13:55 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B346021F8883 for <ipv6@ietfa.amsl.com>; Tue, 5 Mar 2013 05:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3I+RlqCGgaz for <ipv6@ietfa.amsl.com>; Tue, 5 Mar 2013 05:55:16 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CAA6721F8758 for <ipv6@ietf.org>; Tue, 5 Mar 2013 05:55:15 -0800 (PST)
Received: from FB10H117WS01 ([141.89.226.146]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MA9Uv-1U5xOL0wcD-00C4gP; Tue, 05 Mar 2013 08:55:14 -0500
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
References: <7EE61AD6-2E54-4F17-BBFD-30BE77F7E782@gmail.com> <1362476231.3387.278.camel@karl> <1362490400.37136.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <5135F5CA.1090207@gmail.com>
In-Reply-To: <5135F5CA.1090207@gmail.com>
Subject: RE: 6MAN Agenda for IETF86
Date: Tue, 05 Mar 2013 14:55:08 +0100
Message-ID: <006801ce19a9$0ff8bcd0$2fea3670$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4ZpxAP/7bVE1CBQF2eH/cGV6tvVgAAOAqQ
Content-Language: de
X-Provags-ID: V02:K0:VrTC9xrKe2zZQGXZ/gljmH5oz7tKMIXzRMeDOeWvnQl sVze2yh9bUHV2awvDEE9336ittZSp6FujeA5ckGc4iwxNkZQJk Gm6ddnus1/ML/fZVbfWe5pZsouI7hobW7+SBXou2wxaooS3yCC fnIHVNN3OCslQMqISDAff1qZDGMltw7AVvudOVIhY9O9iC+ZfA pFvndb3O68O5qXTPZUAuGTlh+Ss7PGZ0ro0dSYSo9EmT/8KlYO HZ3DV7rRx4iaI0YpgAYR6OzrshhhPOy8TBwmjKOClX1D+qVuYH XSAeRCHWBDDIrmb7mAAiGsJKW1WgpboLYYLH01dmpYgBB+Luzc Wc1s004J31mHcEEn4o54=
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 13:55:16 -0000

In the latest version of my draft RFC,SSAS, l have provided information
about using SSAS for mobile nodes and I have specified the sections of the
RFCs that can use this mechanism. So maybe this can prove useful for
vehicular communication too.
Are the drafts that you mentioned discussed in 6man? I have not seen any
discussions about them. Maybe I missed it. If it is in another WG, would you
please tell me which one?

Thanks,
Hosnieh



-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Alexandru Petrescu
Sent: Dienstag, 5. März 2013 14:40
To: ipv6@ietf.org
Subject: Re: 6MAN Agenda for IETF86

ND security is an important topic.

Let me explain why.

We consider the use of ND over 802.11p links for vehicular communications.
These links dont have ESSID nor link-layer security.
(it is not clear whether it is legal to run IP straight over 80211p, being
"safety apps") but once it becomes clear the security question comes up.

(ND drafts for vehicular communications:
draft-petrescu-autoconf-ra-based-routing
draft-kaiser-nd-pd-01
draft-jhlee-mext-mnpp-00)

The security of ND on these links needs to be fast and easy to set up.

Alex

Le 05/03/2013 14:33, Nalini Elkins a écrit :
> Karl,
>
> I definitely agree that ND needs to be secured.  Also agree that 
> neither IPSec nor SEND are viable solutions.
>
> I do not know if I am missing something but I have not seen a 
> comprehensive document with these problems detailed.  I certainly 
> don't have a solution but I have been trying to at least catalog such
>  problems.   If there is such a document, would appreciate anyone
> letting me know.
>
> If there isn't, if you would like, we can collaborate on such a
> document and create a draft for the IETF meeting in Berlin.   Maybe
> v6Ops is a place to discuss this topic.  Once many at IETF agree that 
> indeed there is a problem, then we can discuss a potential solution.
> Thanks,
>
> Nalini Elkins Inside Products, Inc. (831) 659-8360 
> www.insidethestack.com
>
> ----------------------------------------------------------------------
> --
>
>
*From:* Karl Auer <kauer@biplane.com.au>
> *To:* ipv6@ietf.org *Sent:* Tuesday, March 5, 2013 1:37 AM *Subject:*
> Re: 6MAN Agenda for IETF86
>
> On Mon, 2013-03-04 at 16:02 -0800, Bob Hinden wrote:
>> A Simple Secure Addressing Generation Scheme for IPv6 
>> AutoConfiguration draft-rafiee-6man-ssas-01.txt [...] DHCPv6/SLAAC 
>> Address Configuration Interaction Problem Statement 
>> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>>
>> We did not think there had been enough discussion or interest on the 
>> w.g. list to guarantee a speaking slot.  We allocated short slots at 
>> the end of the session if there is time before the meeting ends.  If 
>> anyone (other than the authors) think one of these should be given 
>> more time, please speak up.
>
> For what it's worth it seems to me that there is a gaping hole around 
> securing ND. IPSec is obviously ridiculous, SEND is only marginally 
> less ridiculous. Maybe SSAS is a way forward? Or maybe noone else 
> thinks ND needs to be secured? Maybe the meeting could attempt to 
> gauge whether this is actually a real problem. I think it is, and I 
> urge others to speak up if they too think this should be pursued.
>
> If there is a priority to these things, then sorting out the perceived 
> and actual discrepancies\ and ambiguities in the meaning of the RA M 
> and O flags would seem pretty important. Otherwise they will end up 
> cemented into even more implementations than they are now. The way 
> Windows handles them is just plain broken, and if the RFCs support 
> that way of handling them, then the RFCs are broken. At very least 
> this topic needs some impetus.
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
>
Karl Auer (kauer@biplane.com.au <mailto:kauer@biplane.com.au>)
> http://www.biplane.com.au/kauer http://www.biplane.com.au/blog
>
> GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old 
> fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org 
> <mailto:ipv6@ietf.org> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------