Subject: [Openv6] A new APONF use case FW: New Version Notification for draft-bi-aponf-sdsavi-00.txt

From: "Jun Bi" <[email-masked]>
Date: Sat, 5 Jul 2014 15:37:09 +0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, July 5, 2014 2:42 AM
To: Jun Bi; Guang Yao; Guang Yao; Jun Bi
Subject: New Version Notification for draft-bi-aponf-sdsavi-00.txt

A new version of I-D, draft-bi-aponf-sdsavi-00.txt has been successfully submitted by Guang Yao and posted to the IETF repository.

Name:		draft-bi-aponf-sdsavi
Revision:	00
Title:		Software Defined SAVI
Document date:	2014-07-04
Group:		Individual Submission
Pages:		4
URL:            http://www.ietf.org/internet-drafts/draft-bi-aponf-sdsavi-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bi-aponf-sdsavi/
Htmlized:       http://tools.ietf.org/html/draft-bi-aponf-sdsavi-00

Abstract:
   This document is about the APONF use case for SAVI.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 7 Jul 2014 07:50:05 +0000

Folks,
I have read this version. I found a typo and have a question.

Introduction

- " and the decide" -> remove "the"

Comments:
- I actually skimmed some of SAVI documents. What I understand from those documents is that they try to create a bindings between the port and the node. So, IMHO, still there might be a risk in initial steps where nodes identify themselves to SAVI device. In this step, if there is a bad guy in the network, he can claim the address of any other nodes. This is , of course, no risk if the IP addresses does not have any meaning. In other words, the IP addresses are not the IP addresses of nodes who are important in the network. I think this risk is almost zero for the case where SeND is in use but when there is DHCP server in use then this risk is still possible since a node can advertise any IP address. So, I guess, in this case for important nodes, even for initial steps, human interaction is needed.

Now the question is how do you plan to handle this when you want to have also a dynamic port? 

Thank you,
Best,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, July 5, 2014 2:42 AM
To: Jun Bi; Guang Yao; Guang Yao; Jun Bi
Subject: New Version Notification for draft-bi-aponf-sdsavi-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
Openv6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/openv6

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 9 Jul 2014 13:19:29 +0800

Dear Hosnieh,

Thank you very much for your comments. 

At first, I can well understand "Openv6", but currently I'm not quite sure
about "APONF". This doc is originally written for "Openv6"; however, I'm
still not sure about it is an APONF-style "application" even after we try to
use the concepts specified in APONF. I think this doc is a requirement doc
rather than a solution design.

I'm not sure I fully understand your question, but I will try to answer it
to my best of my understanding. I think the first step is the SAVI
application should have a way to identify which nodes are important, and
thus their addresses. We suppose such an interface should be provided by
APONF, e.g., it can tells which nodes are servers, which nodes are hosts.
What the SAVI application need is just prevent the hosts from spoofing the
addresses of servers. If the node is dynamic attached, APONF may still have
some way to tell its role, then things will be much the same. 

If APONF does not intent to support this, we will check what APONF can
provide to SAVI and re-design it. Though APONF is supposed to provide an
"Abstract View" to the applications, currently there is not a detailed doc
on it. At least the SAVI application deeply depends on the view can be
achieved. We sincerely expect the doc.

Best regards,
Guang

-----Original Message-----
From: Openv6 [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
Sent: Monday, July 07, 2014 3:50 PM
To: [email-masked]
Subject: Re: [Openv6] A new APONF use case FW: New Version Notification for
draft-bi-aponf-sdsavi-00.txt

Folks,

Introduction

Comments:
- I actually skimmed some of SAVI documents. What I understand from those
documents is that they try to create a bindings between the port and the
node. So, IMHO, still there might be a risk in initial steps where nodes
identify themselves to SAVI device. In this step, if there is a bad guy in
the network, he can claim the address of any other nodes. This is , of
course, no risk if the IP addresses does not have any meaning. In other
words, the IP addresses are not the IP addresses of nodes who are important
in the network. I think this risk is almost zero for the case where SeND is
in use but when there is DHCP server in use then this risk is still possible
since a node can advertise any IP address. So, I guess, in this case for
important nodes, even for initial steps, human interaction is needed.

Now the question is how do you plan to handle this when you want to have
also a dynamic port? 

Thank you,
Best,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, July 5, 2014 2:42 AM
To: Jun Bi; Guang Yao; Guang Yao; Jun Bi
Subject: New Version Notification for draft-bi-aponf-sdsavi-00.txt

A new version of I-D, draft-bi-aponf-sdsavi-00.txt has been successfully
submitted by Guang Yao and posted to the IETF repository.

URL:
http://www.ietf.org/internet-drafts/draft-bi-aponf-sdsavi-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 10 Jul 2014 09:00:14 +0000

Hi Guang,

Thanks for your response and clarifying the plan for the work. You covered my response. :-). By addressing the concern I mentioned, I guess there is no more risk. 

Best,
Hosnieh

-----Original Message-----
From: Guang Yao [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2014 7:19 AM
To: Hosnieh Rafiee; [email-masked]
Subject: RE: [Openv6] A new APONF use case FW: New Version Notification for draft-bi-aponf-sdsavi-00.txt

Dear Hosnieh,

At first, I can well understand "Openv6", but currently I'm not quite sure about "APONF". This doc is originally written for "Openv6"; however, I'm still not sure about it is an APONF-style "application" even after we try to use the concepts specified in APONF. I think this doc is a requirement doc rather than a solution design.

I'm not sure I fully understand your question, but I will try to answer it to my best of my understanding. I think the first step is the SAVI application should have a way to identify which nodes are important, and thus their addresses. We suppose such an interface should be provided by APONF, e.g., it can tells which nodes are servers, which nodes are hosts.
What the SAVI application need is just prevent the hosts from spoofing the addresses of servers. If the node is dynamic attached, APONF may still have some way to tell its role, then things will be much the same. 

If APONF does not intent to support this, we will check what APONF can provide to SAVI and re-design it. Though APONF is supposed to provide an "Abstract View" to the applications, currently there is not a detailed doc on it. At least the SAVI application deeply depends on the view can be achieved. We sincerely expect the doc.

Best regards,
Guang

-----Original Message-----
From: Openv6 [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
Sent: Monday, July 07, 2014 3:50 PM
To: [email-masked]
Subject: Re: [Openv6] A new APONF use case FW: New Version Notification for draft-bi-aponf-sdsavi-00.txt

Folks,

Introduction

Comments:

Thank you,
Best,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, July 5, 2014 2:42 AM
To: Jun Bi; Guang Yao; Guang Yao; Jun Bi
Subject: New Version Notification for draft-bi-aponf-sdsavi-00.txt

Abstract:

The IETF Secretariat