Subject: 6MAN Agenda for IETF86

From: Bob Hinden <[email-masked]>
Date: Mon, 4 Mar 2013 16:02:59 -0800

You can find the current 6MAN agenda at:

    http://www.ietf.org/proceedings/86/agenda/agenda-86-6man

We prioritized drafts that are working group items and drafts that have been actively discussed on the list.  

As you will note in the agenda, there is a "if time allowed" section at the end with short presentations on:

   A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration
	draft-rafiee-6man-ssas-01.txt
   6LoWPAN Backbone Router
	draft-thubert-6lowpan-backbone-router-02.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.

Thanks,
Bob & Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Mar 2013 08:15:51 +0000

Bob

> 	draft-liu-bonica-dhcpv6-slaac-problem-01.txt

I think this is a very important topic. Its impact might seem to fall
more in v6ops territory, and it also has relevance to mif and homenet,
but only 6man (IMHO) can fix it. Unfortunately I won't be in Orlando,
and I don't really care about a face to face debate, but the WG really
should take up this topic.

Regards
   Brian

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 10:00:05 +0100

Dear All,

I am sorry, it took a while that I could revise and apply comments to the
draft. But, unfortunately there was not enough time to upload a new version
and I could just upload a version with a few revision. I would ask you again
to consider the presentation as it would be a great chance to show all about
the differences of this approach with CGA and the application of it.

Thank you,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob
Hinden
Sent: Dienstag, 5. März 2013 01:03
To: IPv6 List
Cc: Bob Hinden
Subject: 6MAN Agenda for IETF86

We prioritized drafts that are working group items and drafts that have been
actively discussed on the list.  

As you will note in the agenda, there is a "if time allowed" section at the
end with short presentations on:

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.

Thanks,
Bob & Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Tue, 05 Mar 2013 20:37:11 +1100

On Mon, 2013-03-04 at 16:02 -0800, Bob Hinden wrote:
> [...]
> 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 ([email-masked])
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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Mar 2013 10:39:17 +0000

Bob,

The agenda shows an obsolete version for draft-carpenter-6man-ext-transmit-02.
The changes are significant!

Regards
   Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Mar 2013 11:44:26 +0100

Brian,

> The changes are significant!

thanks, fixed.

cheers,
Ole

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 12:25:57 +0100

Dear All,
I would appreciate if you explain your criteria for assigning time slot to
the drafts while other drafts discussed on the mailing list too.  
The recent discussion on the list about the following drafts that you
assigned the time slot.

draft-boucadair-6man-multicast-addr-arch  : 3 discussion on the list : 20
mins
draft-carpenter-6man-ug  : +10 discussion on the list : 10 mins
draft-carpenter-6man-ext-transmit  : 3 discussion on the list  : 15 mins
draft-gont-6man-ipv6-smurf-amplifier : 2 discussion on the list : 15 mins
draft-brandt-6man-lowpanz  : 1 discussion on the list : 10 mins

http://www.ietf.org/mail-archive/web/ipv6/current/maillist.html

Thank you,
Hosnieh

-----Original Message-----

Thanks,
Bob & Ole

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 14:14:16 +0100

Follow up

In my last email I asked about what criteria was being used because it seems
to me that giving time slots to some drafts and almost none to others wasn't
based on the criteria that you mentioned.
- none of the selected drafts which have been assigned a time slot are WG
drafts so this cannot be based on your stated criteria
- according to my last email, some of these drafts have had only 1 "mailing
list" discussion (omitting authors) so having had more discussions does not
meet your stated criteria for selection.

If there are other criteria being used that I have missed, I would
appreciate an explanation of what they are. 
What would actually be fair in assigning time slots would be to give
something like 10 minutes to all active drafts on the list so that everyone
could count on an opportunity to discuss their drafts. 

If I am wrong please tell me.

Thank you,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hosnieh Rafiee
Sent: Dienstag, 5. März 2013 12:26
To: 'Bob Hinden'; 'Ole Troan'
Cc: [email-masked]
Subject: RE: 6MAN Agenda for IETF86

Dear All,

mins draft-carpenter-6man-ug  : +10 discussion on the list : 10 mins

Thank you,
Hosnieh

-----Original Message-----

Thanks,
Bob & Ole

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Mar 2013 05:33:20 -0800 (PST)

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 <[email-masked]>
To: [email-masked] 
Sent: Tuesday, March 5, 2013 1:37 AM
Subject: Re: 6MAN Agenda for IETF86

Regards, K.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Mar 2013 14:40:26 +0100

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 <[email-masked]>
> *To:* [email-masked] *Sent:* Tuesday, March 5, 2013 1:37 AM *Subject:*
> Re: 6MAN Agenda for IETF86
>
>> A Simple Secure Addressing Generation Scheme for IPv6
>> AutoConfiguration draft-rafiee-6man-ssas-01.txt [...] DHCPv6/SLAAC
>> Address Configuration Interaction Problem Statement
>> 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 ([email-masked] <mailto:[email-masked]>)
> http://www.biplane.com.au/kauer http://www.biplane.com.au/blog
>
> IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 14:45:28 +0100

Dear Nalini,

Our draft http://tools.ietf.org/html/draft-rafiee-6man-ssas-02 talks about a
solution for securing ND while also considering privacy. You can read this
version, however, I will be uploading the latest version on 11 March when
IETF is again open for submissions. 

If after reading it, if you have any comments I would appreciate your input
so that I can add them to this latest draft.

Thanks,

Hosnieh

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nalini Elkins
Sent: Dienstag, 5. März 2013 14:33
To: Karl Auer; [email-masked]
Subject: Re: 6MAN Agenda for IETF86

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

  _____  

On Mon, 2013-03-04 at 16:02 -0800, Bob Hinden wrote:
> AutoConfiguration

Regards, K.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 14:55:08 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Dienstag, 5. März 2013 14:40
To: [email-masked]
Subject: Re: 6MAN Agenda for IETF86

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.

Alex

> 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.
>
> 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.
>
> --
> GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old 
> fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
>
>

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Mar 2013 05:58:29 -0800 (PST)

Hosnieh,

I will read and respond.   Thank you for working on a solution to this important problem.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Hosnieh Rafiee <[email-masked]>
To: 'Nalini Elkins' <[email-masked]> 
Cc: [email-masked]; 'Karl Auer' <[email-masked]> 
Sent: Tuesday, March 5, 2013 5:45 AM
Subject: RE: 6MAN Agenda for IETF86

Dear Nalini,
 
Our draft http://tools.ietf.org/html/draft-rafiee-6man-ssas-02 talks about a solution for securing ND while also considering privacy. You can read this version, however, I will be uploading the latest version on 11 March when IETF is again open for submissions. 
If after reading it, if you have any comments I would appreciate your input so that I can add them to this latest draft.
 
Thanks,
Hosnieh

From:[email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: Dienstag, 5. März 2013 14:33
To: Karl Auer; [email-masked]
Subject: Re: 6MAN Agenda for IETF86
 
Karl,

 
 
Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

From:Karl Auer <[email-masked]>
To: [email-masked] 
Sent: Tuesday, March 5, 2013 1:37 AM
Subject: Re: 6MAN Agenda for IETF86

Regards, K.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Mar 2013 15:41:40 +0100

Hosnieh,

I would have to read the draft and feed back about SSAS.

Some of the drafts I mentioned (ND-PD) were presented to 6MAN meeting in
Atlanta, and discussed on the email list.  One of the drafts
(draft-jhlee-mext-mnpp-00) is considered at ISO, but I dont know its status.

Another draft which generates IID from VIN (Vehicular Identification
Number) we discussed recently in the 6MAN email list is:
draft-imadali-its-vinipv6-viid-00.txt

We don't have a WG about vehicular communications but we have an email
list ITS for Intelligent Transportation Systems
(ietf.org/mailman/listinfo/its).  We discuss a Charter proposal there.

Alex

Le 05/03/2013 14:55, Hosnieh Rafiee a écrit :
> 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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Dienstag, 5. März 2013 14:40 To: [email-masked] Subject: Re: 6MAN
> Agenda for IETF86
>
>  (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.
>
> draft-petrescu-autoconf-ra-based-routing draft-kaiser-nd-pd-01
>> 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.
>>
>> 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,
>>
>> ----------------------------------------------------------------------
>>
>>
>>
--
>> *To:* [email-masked] *Sent:* Tuesday, March 5, 2013 1:37 AM
>> *Subject:* Re: 6MAN Agenda for IETF86
>>
>>> AutoConfiguration draft-rafiee-6man-ssas-01.txt [...]
>>> 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.
>>
>> 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.
>>
>> 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.
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
~

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Mar 2013 07:24:48 -0800 (PST)

Guys,

I am going to go back and review "IPv6 Neighbor Discovery (ND) Trust Models and Threats: RFC 3756"

http://datatracker.ietf.org/doc/rfc3756/

For all who think that ND and RA in particular does not have problems, here is a UTube video of a hacker at work using RA.

http://www.youtube.com/watch?v=TfsfNWHCKK0

Next, there is an interesting web site: http://www.thc.org/thc-ipv6/

You can see the "interesting" tools available:

dnssecwalk - performs NSEC walking including Iv6+IPv4 resolving
firewall6 - various TCP/UDP ACL bypass test cases
fake_pim6 - send fake hello and join/prune pim messages
ndpexhaust26 - very performant ndp exhauster based on ICMP error toobig messages but can send many types of packets
alive6: ranges are now supported in the input file too
parasite6: enhancements to make it way more effective
fake_router26: added overlap RA guard evasion type (-E o, -E O)
dos-new-ip6: fix that only DAD replies are sent, not full NDP spoofing 
flood_router26: Added local LAN privacy extension prevention attack
randicmp6: - added function which dumps icmp answers received - added funtionality to send a specific type (and also code)
dnsdict6: added SRV result address resolving

and others.

I will review all drafts with the above in mind.

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
From: Alexandru Petrescu <[email-masked]>
To: Hosnieh Rafiee <[email-masked]> 
Cc: [email-masked] 
Sent: Tuesday, March 5, 2013 6:41 AM
Subject: Re: 6MAN Agenda for IETF86

Hosnieh,

Alex

--
~
>> http://www.biplane.com.au/kauerhttp://www.biplane.com.au/blog
>>

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 16:43:06 +0100

Dear Nalini,

Yes. That RFC is an old RFC that explained the most probable attacks that
could be used against ND. This is the main reason that ND is not at all
secure and the people who think that just privacy is enough (like what was
just implemented in windows) are making a big mistake.

In our lab we are currently working on devising possible attacks against
IPv6 networks in order to find ways of preventing them. We hope to be able
to provide the necessary tools to provide the security necessary to use
against these many different types of attack. 

Thank you,
Hosnieh

-----Original Message-----
From: Nalini Elkins [mailto:[email-masked]] 
Sent: Dienstag, 5. März 2013 16:25
To: Alexandru Petrescu; Hosnieh Rafiee; Karl Auer
Cc: [email-masked]
Subject: Re: 6MAN Agenda for IETF86

Guys,

I am going to go back and review "IPv6 Neighbor Discovery (ND) Trust Models
and Threats: RFC 3756"

For all who think that ND and RA in particular does not have problems, here
is a UTube video of a hacker at work using RA.

dnssecwalk - performs NSEC walking including Iv6+IPv4 resolving
firewall6 - various TCP/UDP ACL bypass test cases
fake_pim6 - send fake hello and join/prune pim messages
ndpexhaust26 - very performant ndp exhauster based on ICMP error toobig
messages but can send many types of packets
alive6: ranges are now supported in the input file too
parasite6: enhancements to make it way more effective
fake_router26: added overlap RA guard evasion type (-E o, -E O)
dos-new-ip6: fix that only DAD replies are sent, not full NDP spoofing
flood_router26: Added local LAN privacy extension prevention attack
randicmp6: - added function which dumps icmp answers received - added
funtionality to send a specific type (and also code)
dnsdict6: added SRV result address resolving

and others.

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

Hosnieh,

We don't have a WG about vehicular communications but we have an email list
ITS for Intelligent Transportation Systems (ietf.org/mailman/listinfo/its). 
We discuss a Charter proposal there.

Alex

Le 05/03/2013 14:55, Hosnieh Rafiee a écrit :
> 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
>
>
>
--
~

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 5 Mar 2013 07:53:51 -0800 (PST)

Hosnieh,

Very interesting!  We ourselves are working on the same project!  A toolkit to help people protect themselves against IPv6 attacks.  I think the time has definitely come.

Please contact me offline if you would like to collaborate.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

----- Original Message -----
From: Hosnieh Rafiee <[email-masked]>
To: 'Nalini Elkins' <[email-masked]>
Cc: [email-masked]; 'Alexandru Petrescu' <[email-masked]>; 'Karl Auer' <[email-masked]>
Sent: Tuesday, March 5, 2013 7:43 AM
Subject: RE: 6MAN Agenda for IETF86

Dear Nalini,

Thank you,
Hosnieh

-----Original Message-----
From: Nalini Elkins [mailto:[email-masked]] 
Sent: Dienstag, 5. März 2013 16:25
To: Alexandru Petrescu; Hosnieh Rafiee; Karl Auer
Cc: [email-masked]
Subject: Re: 6MAN Agenda for IETF86

Guys,

and others.

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

Hosnieh,

Alex

--
~

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Mar 2013 13:48:13 -0500

>>>>> "Karl" == Karl Auer <[email-masked]> writes:
    >> these should be given more time, please speak up.

    Karl> For what it's worth it seems to me that there is a gaping hole
    Karl> around securing ND. IPSec is obviously ridiculous, SEND is
    Karl> only marginally less ridiculous. Maybe SSAS is a way forward? 

SEND looked at AH and realized that it couldn't be used, so IPsec is a
non-starter.  I'd like to know what you know about SEND that the SEND WG
didn't...

SASS is similar, but uses a different algorithm, and you don't have to
recalculate each time you move.  For nodes that don't move, it seems
identical.

-- 
Michael Richardson
-on the road-

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 20:28:45 +0100

This is not true.  I think that you  have confused this draft with another
draft that was not about security but had the title "Stable Privacy
Addresses". Otherwise you are saying that you do not want to observe privacy
at all. The nodes' IP addresses are valid for a certain period of time which
is dependent on the network policy in vogue. In the draft, in several
sections, the need to change the IP address for privacy is  emphasized. 

It seems that I have to upload the latest version of my draft to a website
where others can read it. 

Thank you,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Richardson
Sent: Tuesday, March 05, 2013 7:48 PM
To: Karl Auer
Cc: [email-masked]
Subject: Re: 6MAN Agenda for IETF86

--
Michael Richardson
-on the road-

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Mar 2013 12:17:41 -0800 (PST)

Hi,

----- Original Message -----
> From: Michael Richardson <[email-masked]>
> To: Karl Auer <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, 6 March 2013 5:48 AM
>     >> 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.
> 

I'm curious what the specific problem with SEND is. Is it the lack of commonly available implementations, or the manual work to bootstrap it (IIRC that is required), or both? The IETF obviously can't solve the former. If it is the latter, I wonder if the "Better-Than-Nothing" model, used for IPsec in RFC5386, could be applied to SEND? 

Regards,
Mark.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Mar 2013 21:42:47 +0100

> 	draft-thubert-6lowpan-backbone-router-02.txt

That actually has received more discussion back in 2010...
(I think you want to point to -03.)

An earlier version of that draft received even more discussion while it was part of what is now RFC 6775, i.e. between 2008 and 2010.

More generally, this draft could also be relevant as a potential input to having multiple routers collaborate implementing efficient-nd.

In summary, I'd prefer if this didn't fall off the cliff.

Grüße, Carsten

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 5 Mar 2013 22:01:58 +0100

Dear Mark,

>I'm curious what the specific problem with SEND is. Is it the lack of
commonly available implementations, or the manual work to bootstrap it (IIRC
that is required), or both? The IETF obviously can't >solve the former. If
it is the latter, I wonder if the "Better-Than-Nothing" model, used for
IPsec in RFC5386, could be applied to SEND?

One problem with SEND is that the time it takes for the CGA algorithm
generation is not fast enough for IP address generation and more importantly
the verification process using CGA is not fast enough either. A second
problem concerns the Public Key Infrastructure.
For the first problem, I offered the use of SSAS which is faster. For the
second problem I have another solution, but first I need to check some of
the other new RFCs about Certification and  I will do this before the IETF
meeting so that I can also include it in my draft.

Thank you,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Smith
Sent: Tuesday, March 05, 2013 9:18 PM
To: Michael Richardson; Karl Auer
Cc: [email-masked]
Subject: Re: 6MAN Agenda for IETF86

Hi,

----- Original Message -----
> non-starter.  I'd like to know what you know about SEND that the SEND 
> WG didn't...
> 

I'm curious what the specific problem with SEND is. Is it the lack of
commonly available implementations, or the manual work to bootstrap it (IIRC
that is required), or both? The IETF obviously can't solve the former. If it
is the latter, I wonder if the "Better-Than-Nothing" model, used for IPsec
in RFC5386, could be applied to SEND? 

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Mar 2013 14:42:48 -0800

Hosneih,

It was a mix of things the chairs thought where important and prior history of the work.  We also, of course, have a fixed amount of time and can't accommodate everything.

See specific comments below.

Bob & Ole

> draft-boucadair-6man-multicast-addr-arch  : 3 discussion on the list : 20

This is an update from earlier w.g. meetings (there has been a lot of email discussion and presentations).  The chairs and the AD think this is a reasonable compromise to go forward with.

> draft-carpenter-6man-ug  : +10 discussion on the list : 10 mins

Considerable discussion in this and U&G bits in general.

> draft-carpenter-6man-ext-transmit  : 3 discussion on the list  : 15 mins

This is a followup from the previous IETF meeting, the chairs think it's an important issue to resolve, especially creating an IANA registry for IPv6 extension headers.

> draft-gont-6man-ipv6-smurf-amplifier : 2 discussion on the list : 15 mins

This was the chairs call as we thought there would be interest in it.  Given the discussion on the list, there appears to be more interest in <draft-liu-bonica-dhcpv6-slaac-problem-01.txt> and we propose to swap them.  There isn't time for everything.

Comments?

> draft-brandt-6man-lowpanz  : 1 discussion on the list : 10 mins

This is an IPv6 over Foo document.  The IPv6 w.g. is the appropriate place to standardize these kind of documents.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Mar 2013 14:48:59 -0800

Carsten,

> (I think you want to point to -03.)

Fixed.  

> In summary, I'd prefer if this didn't fall off the cliff.

It won't fall off the cliff, just isn't getting very much agenda time in Orlando.

Bob

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 5 Mar 2013 23:20:54 +0000

> More generally, this draft could also be relevant as a potential input to having multiple routers collaborate implementing efficient-nd.

SC>
Correct. I believe the goal of the presentation for this draft is to seek input from the wg regarding its relevance with efficient-nd. So, as a co-author of efficient-nd, I'd also like to see this document to get a few minutes to discuss those ideas with the working group.

Thanks,
-Samita

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 6 Mar 2013 00:45:17 +0100

Dear Bob,

Thanks for the explanation. I would ask that you correct the version number
of my draft to 2 in the following link:
http://www.ietf.org/proceedings/86/agenda/agenda-86-6man . I would also ask
that I at least be given some time to explain the purpose of this draft and
the differences between the current mechanisms.
It appears that my draft has not been added to those of the 6man drafts, at
least I can't find it and it is also missing from the PDF agenda, while all
other drafts are listed at your link:
https://datatracker.ietf.org/meeting/86/agenda.html.

Thank you,
Hosnieh

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Tuesday, March 05, 2013 11:43 PM
To: Hosnieh Rafiee
Cc: Bob Hinden; 'Ole Troan'; [email-masked]
Subject: Re: 6MAN Agenda for IETF86

Hosneih,

It was a mix of things the chairs thought where important and prior history
of the work.  We also, of course, have a fixed amount of time and can't
accommodate everything.

Bob & Ole

On Mar 5, 2013, at 3:25 AM, Hosnieh Rafiee wrote:

> Dear All,
> I would appreciate if you explain your criteria for assigning time 
> slot to the drafts while other drafts discussed on the mailing list too.
> draft-boucadair-6man-multicast-addr-arch  : 3 discussion on the list : 
> 20 mins

This is an update from earlier w.g. meetings (there has been a lot of email
discussion and presentations).  The chairs and the AD think this is a
reasonable compromise to go forward with.

> draft-carpenter-6man-ext-transmit  : 3 discussion on the list  : 15 

This is a followup from the previous IETF meeting, the chairs think it's an
important issue to resolve, especially creating an IANA registry for IPv6
extension headers.

> draft-gont-6man-ipv6-smurf-amplifier : 2 discussion on the list : 15 

This was the chairs call as we thought there would be interest in it.  Given
the discussion on the list, there appears to be more interest in
<draft-liu-bonica-dhcpv6-slaac-problem-01.txt> and we propose to swap them.
There isn't time for everything.

Comments?

> draft-brandt-6man-lowpanz  : 1 discussion on the list : 10 mins

This is an IPv6 over Foo document.  The IPv6 w.g. is the appropriate place
to standardize these kind of documents.  

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Bob Hinden
> We prioritized drafts that are working group items and drafts that 
> have been actively discussed on the list.
> 
> 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.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Mar 2013 16:16:34 -0800

Hosnieh,

On Mar 5, 2013, at 3:45 PM, Hosnieh Rafiee wrote:

> http://www.ietf.org/proceedings/86/agenda/agenda-86-6man .

Fixed.

> I would also ask

Assume we run on time, you should have time for that.  

> https://datatracker.ietf.org/meeting/86/agenda.html.

I don't have any control over that, must be some delay from when it is updated.  Try reloading the page.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Mar 2013 12:31:00 -0500

>>>>> "Hosnieh" == Hosnieh Rafiee <[email-masked]> writes:
    Hosnieh> This is not true.  I think that you have confused this
    Hosnieh> draft with another draft that was not about security but
    Hosnieh> had the title "Stable Privacy Addresses". Otherwise you are
    Hosnieh> saying that you do not want to observe privacy at all. The

No, I don't want my web server or my fridge to observe privacy.
I want them in the DNS, and reachable.

I do want to keep layer-3 attacks on ND from permitting other web
servers in that data centre from impersonating my machine, or from a
malicious visitor to my house from ordering too much caviar.

    Hosnieh> It seems that I have to upload the latest version of my
    Hosnieh> draft to a website where others can read it.

this is the document that I read: draft-rafiee-6man-ssas-01.txt

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 6 Mar 2013 19:14:14 +0100

Dear Michael,

To observe privacy without sacrificing security in DNS I have another draft
that considers the use of both CGA and SSAS. In this case you can have both
privacy and security at the same time by using SSAS which is more practical
than CGA.
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-02

> this is the document that I read: draft-rafiee-6man-ssas-01.txt

The second version is available and I am working on third version which will
contain many revisions.

Thanks,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Richardson
Sent: Wednesday, March 06, 2013 6:31 PM
To: Hosnieh Rafiee
Cc: Karl Auer; [email-masked]
Subject: Re: 6MAN Agenda for IETF86

I do want to keep layer-3 attacks on ND from permitting other web servers in
that data centre from impersonating my machine, or from a malicious visitor
to my house from ordering too much caviar.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Mar 2013 00:27:11 -0300

Bob,

On 03/05/2013 07:42 PM, Bob Hinden wrote:
> This was the chairs call as we thought there would be interest in it.
> Given the discussion on the list, there appears to be more interest
> in <draft-liu-bonica-dhcpv6-slaac-problem-01.txt> and we propose to
> swap them.  There isn't time for everything.
> 
> Comments?

I personally oppose to such idea. This is my reasoning:

* draft-gont-6man-ipv6-smurf-amplifier has already been in the position
of "this will be discussed if time permits" (and at the time, time
didn't permit). Hence it's time to allocate a slot to this I-D. The same
reasoning should apply to draft-liu-bonica-dhcpv6-slaac-problem-01.txt
for the next IETF meeting.

* draft-gont-6man-ipv6-smurf-amplifier is pretty much straight-forward
so that may be one reason for which you didn't see more discussion about
it. I'd expect that discussion during the 6man wg meeting will be brief,
and hence we'll be able to move forward to the next document even before
the allocated time is used.

* Changing agendas once published is, IMO, a bad idea (unless really
necessary).

FWIW, I should note that I do support
draft-liu-bonica-dhcpv6-slaac-problem-01.txt -- i.e., the reasoning
above doesn't have anything to do with the contents of
draft-liu-bonica-dhcpv6-slaac-problem-01.txt itself.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Mar 2013 05:06:50 -0300

Hi, Bob,

Please replace the link to
<http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-00>
with a link to
<http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-02>

Thanks!

Cheers,
Fernando

---

From: Doug Barton <[email-masked]>
Date: Fri, 08 Mar 2013 03:09:43 -0800

> <http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-02>

It's better to leave the -NN off the end altogether, then the tools site 
will do the right thing.

Doug