Subject: [mif] questions on draft-ietf-mif-api-extension

From: <[email-masked]>
Date: Tue, 25 Sep 2012 15:36:51 +0000

Hi Ted, Dapeng,

I have few questions about draft-ietf-mif-api-extension:

A subscriber can subscribe to configuration element and address announcements (respectively sections 3.5.9 and 3.5.13); however a subscriber cannot unsubscribe, i.e. neither "Stop announcing configuration element" nor "Stop announcing address" are specified in the I-D. Is there a reason to this?

In sections 3.5.23.4 and 3.5.23.5: messages are "interface is going away" and "interface is going up". However, according to examples given (interfaces switched on/off) these notification messages are sent when the interface is already down or up. So, I think "is going" is confusing here, maybe these messages should be "interface down" and "interface up", right?

What is the difference between notifications "interface is going down/up" (sections 3.5.23.4 and 3.5.23.5) and interface announcement/no interface announcement in section  3.5.3 and 3.5.4? IMHO, the application subscribes to interface announcement and resulting announcements are the same as "interface is going down/up", so I think there no need for specific messages 3.5.23.4 and 3.5.23.5.

We have a "get configuration data", shouldn't we have a "set configuration data" as well?

Br,
Pierrick

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Sep 2012 15:54:07 +0000

> A subscriber can subscribe to configuration element and address announcements (respectively sections 3.5.9 and 3.5.13); however a subscriber cannot unsubscribe, i.e. neither "Stop announcing config…

No, I think it's an oversight.

> In sections 3.5.23.4 and 3.5.23.5: messages are "interface is going away" and "interface is going up". However, according to examples given (interfaces switched on/off) these notification messages…

This section needs work.   There actually should be a notification that the interface is still up but that the system intends to take it down; there should be another when it is in fact down.

> What is the difference between notifications "interface is going down/up" (sections 3.5.23.4 and 3.5.23.5) and interface announcement/no interface announcement in section  3.5.3 and 3.5.4? IMHO, th…

Interface announce just announces the presence of an interface that may have identity associations.   Typically when an application starts, there will already be a set of interfaces; as soon as the application subscribes to the interface announcement message, it will get an announcement for each such interface.

> We have a "get configuration data", shouldn't we have a "set configuration data" as well?

No, I don't think so.   Configuration data comes from either on-host, static configuration, or from dynamic protocols like RA and DHCP.   What would be the context for an application pushing configuration information up?   This just sounds like an attack vector to me—a malicious app could capture traffic from another app by gaming the configuration settings.

---

From: <[email-masked]>
Date: Wed, 26 Sep 2012 08:27:22 +0000

Hi Ted,

Thanks for super fast answer :-) please see inline for comments.

Pierrick
> -----Message d'origine-----
> De : Ted Lemon [mailto:[email-masked]]
> Envoyé : mardi 25 septembre 2012 17:54
> À : SEITE Pierrick RD-RESA
> Cc : Dapeng Liu; [email-masked]
> Objet : Re: questions on draft-ietf-mif-api-extension
> 
> > A subscriber can subscribe to configuration element and address
> announcements (respectively sections 3.5.9 and 3.5.13); however a
> subscriber cannot unsubscribe, i.e. neither "Stop announcing
> configuration element" nor "Stop announcing address" are specified in
> the I-D. Is there a reason to this?
> 
> > In sections 3.5.23.4 and 3.5.23.5: messages are "interface is going
> away" and "interface is going up". However, according to examples given
> (interfaces switched on/off) these notification messages are sent when
> the interface is already down or up. So, I think "is going" is
> confusing here, maybe these messages should be "interface down" and
> "interface up", right?
> 
> This section needs work.   There actually should be a notification that
> the interface is still up but that the system intends to take it down;
> there should be another when it is in fact down.
> 

Ok, I see. I agree, we need  Interface_going_down and Interface_going_up to "prepare" the application for a future change of the interface status.

We also need for reactive notifications Interface_down (the interface went down suddenly, e.g loss of wi-fi coverage, user switched off the interface) and Interface_up. Here, I guess it can be done with "Interface announcement" and  "no Interface announcement", right?

> > What is the difference between notifications "interface is going
> down/up" (sections 3.5.23.4 and 3.5.23.5) and interface announcement/no
> interface announcement in section  3.5.3 and 3.5.4? IMHO, the
> application subscribes to interface announcement and resulting
> announcements are the same as "interface is going down/up", so I think
> there no need for specific messages 3.5.23.4 and 3.5.23.5.
> 
> Interface announce just announces the presence of an interface that may
> have identity associations.   Typically when an application starts,
> there will already be a set of interfaces; as soon as the application
> subscribes to the interface announcement message, it will get an
> announcement for each such interface.
> 

Ok, understood.

> No, I don't think so.   Configuration data comes from either on-host,
> static configuration, or from dynamic protocols like RA and DHCP.
> What would be the context for an application pushing configuration
> information up?  

I'm thinking about the case where the application is a connection manager. After making a decision, e.g. regarding the mapping of a flow to a given interface, the connection manager needs to associate a routing table to the flow, configure NAT, modify firewall rules and policy table for source address selection,... 

 This just sounds like an attack vector to me-a
> malicious app could capture traffic from another app by gaming the
> configuration settings.

Well, currently, connection managers can leverage on kernel tools (e.g. Linux/iptables) to dynamically influence the configuration. So, if we consider that the MIF API should be the unique interface for manipulation of IP objects, IMHO, "set configuration" should be part of the MIF API services.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2012 12:54:37 +0000

> We also need for reactive notifications Interface_down (the interface went down suddenly, e.g loss of wi-fi coverage, user switched off the interface) and Interface_up. Here, I guess it can be done…

Yes.   Of course, the fact that you are asking these questions means that the document needs work!

> I'm thinking about the case where the application is a connection manager. After making a decision, e.g. regarding the mapping of a flow to a given interface, the connection manager needs to associ…

Yes, if you want to implement a connection manager, you will need additional API functionality.   When we originally scoped the document, we assumed that the connection manager was implicitly *part* of the MIF API, rather than a customer of it.   Of course the expectation is that some parts of the MIF API would be usable by the connection manager, but that the connection manager would require an extensively richer API.

I think in this discussion that it's important to think about who could benefit from the document.   It sounds like you have a wish to have a document that would allow you to implement a connection manager, perhaps one that could show the same behavior across different handsets produced by different manufacturers.   If that's your motivation, it's certainly a valid use case for a MIF API.

However, when we originally scoped this, we were not including that as part of the intended set of users for the documents—we were specifically targeting applications.   Part of the reason for this was the understanding that most existing devices that we had in mind (e.g., iOS devices and Android devices) already had a pretty complete connection manager function, and that we didn't have the expertise to tell Apple or Google how to do a connection manager—that was expertise that they had already developed in-house, and we would expect substantial resistance to us trying to get them to actually do an API like that.

That's not to say that such an API is a bad idea, but it's definitely scope creep for the work we are doing now.   If you are interested in having an API with this functionality, I would argue that it ought to be presented as a supplementary API to the current document, rather than being added on to the current document.   Otherwise, I don't think we have any hope of completing the current document in a timely manner (it could be argued that we have already failed to do so). 

What I would encourage you to do if you want to go down this path is think about the current document in terms of what it might _prevent_ you from doing in the supplementary document, and ask us to fix those bits.

---

From: <[email-masked]>
Date: Wed, 26 Sep 2012 13:36:39 +0000

> Envoyé : mercredi 26 septembre 2012 14:55
> Cc : [email-masked]
> > We also need for reactive notifications Interface_down (the interface
> went down suddenly, e.g loss of wi-fi coverage, user switched off the
> interface) and Interface_up. Here, I guess it can be done with
> "Interface announcement" and  "no Interface announcement", right?
> 

Sorry for asking stupid question :-) but I just want to be sure to understand correctly the current MIF API :-) 

> > I'm thinking about the case where the application is a connection
> manager. After making a decision, e.g. regarding the mapping of a flow
> to a given interface, the connection manager needs to associate a
> routing table to the flow, configure NAT, modify firewall rules and
> policy table for source address selection,...
> 
> Yes, if you want to implement a connection manager, you will need
> additional API functionality.   When we originally scoped the document,
> we assumed that the connection manager was implicitly *part* of the MIF
> API, rather than a customer of it.   Of course the expectation is that
> some parts of the MIF API would be usable by the connection manager,
> but that the connection manager would require an extensively richer
> API.
> 	

> I think in this discussion that it's important to think about who could
> benefit from the document.   It sounds like you have a wish to have a
> document that would allow you to implement a connection manager,
> perhaps one that could show the same behavior across different handsets
> produced by different manufacturers.   If that's your motivation, 

Exactly :-)

it's
> certainly a valid use case for a MIF API.
> 
> However, when we originally scoped this, we were not including that as
> part of the intended set of users for the documents-we were
> specifically targeting applications.   Part of the reason for this was
> the understanding that most existing devices that we had in mind (e.g.,
> iOS devices and Android devices) already had a pretty complete
> connection manager function, and that we didn't have the expertise to
> tell Apple or Google how to do a connection manager-that was expertise
> that they had already developed in-house, and we would expect
> substantial resistance to us trying to get them to actually do an API
> like that.
> 	

I couldn't agree more. My intention is clearly not to specify a connection manager in MIF.
I'm trying to figure out what services/messages, from the MIF API (or MIF API+ OS API), can be useful for connection manager developers. 

> That's not to say that such an API is a bad idea, but it's definitely
> scope creep for the work we are doing now.   If you are interested in
> having an API with this functionality, I would argue that it ought to
> be presented as a supplementary API to the current document, rather
> than being added on to the current document.   

Actually, Juan-Carlos and myself have submitted a discussion draft to address this point. Now, I understand better the purpose of the MIF API and we need to revise according to your feedback. Hopefully, we'll be ready to discuss it at the next IETF.

> Otherwise, I don't think we have any hope of completing the current document in a timely manner
> (it could be argued that we have already failed to do so).
> 
> What I would encourage you to do if you want to go down this path is
> think about the current document in terms of what it might _prevent_
> you from doing in the supplementary document, and ask us to fix those
> bits.

I see.

Thanks again for your feedback.

Pierrick

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2012 14:31:42 +0000

> Actually, Juan-Carlos and myself have submitted a discussion draft to address this point. Now, I understand better the purpose of the MIF API and we need to revise according to your feedback. Hopef…

Yup, I was happy to see that, but haven't had time to read it yet.   If you get a new version out before the next IETF, I'll be ready to discuss it with you there.   :)