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

[<[e-mail]>]

Hi Ted,

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

Pierrick
> -----Message d'origine-----
> De : Ted Lemon [mailto:[e-mail]]
> Envoyé : mardi 25 septembre 2012 17:54
> À : SEITE Pierrick RD-RESA
> Cc : Dapeng Liu; [e-mail]
> Objet : Re: questions on draft-ietf-mif-api-extension
> 
> On Sep 25, 2012, at 11:36 AM, <[e-mail]>
>  wrote:
> > 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?
> 
> 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 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.

> > 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?  

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. 	

_________________________________________________________________________________________________________________________

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.