Subject: Modularity as a requirement?

From: Paal Engelstad <[email-masked]>
Date: Thu, 7 Feb 2002 20:52:00 +0100

George,

Comments below,

> 
> Fra: George Tsirtsis <[email-masked]>
> Dato: 2002/02/07 Thu PM 02:43:29 CET
> Til: "'Hesham Soliman (ERA)'" <[email-masked]>
> CC: [email-masked]
> Tema: RE: RE: draft-ietf-pana-usage-scenarios-00.txt
> 
> Hesham,
> 
> I agree with what you are saying but I am also thinking actual solutions and
> here is a problem.
> 
> I think it would be nice to have a *default* DI that everyone supports. A
> good one would be the IP address of the end node. The problem is that as we
> have discussed a lot of times, PANA may happen before address allocation in
> which case we are in trouble. For this reason I always thought (personal
> rather than design team opinion) that the DI should not be carried in PANA.
> Instead the PAA will need to know what the DI is and use whatever mechanism
> it has to authorize traffic with it (install an access filter in an access
> router) i.e.: DI is just a *hook* for authorization.
> 
> Now in the future, we may want to think about DI negotiations were the MN
> requests access to a potentially complex set of DIs (IP addresses, port
> numbers, mcast services, QoS levels etc) and the network accepts some,
> reject some others etc etc. This would add Access Control capabilities to
> the PANA protocol.
> 
> For good reasons, we currently have Access Control as being out of scope of
> PANA and I think this is a good thing. Access Control is powerful but also
> very complex and a bit of a can of worms like capability discovery partly
> because no one is actually doing it between the end node the network but
> only between the AAA server and the access router. By limiting PANA to
> *authentication* and providing a hook for authorization it is more likely
> that we will come up with a good solution that does on thing well. Then we
> can have long and interesting discussions about how to extend the protocol
> or how to add functionality in a nice, modular way.

I fully agree with all you are saying. 

Perhaps the last sentence about modularity should be added into the requirement document. 

Something like:

"The functionality entities that comprise the PANA protocol include discovery, message carrier, initial authentication, re-authentication and disconnect. Each entitity should be specified as a module, with a clearly defined interface to the other modules."

If we make a flaw in PANA release 1, we may simply swap the flawed module for a new one in release 2.

What do you think?

Paal

> 
> I hope the WG will share my thinking on this one because to me makes the
> difference between doing something simple and useful from meshing the whole
> thing up big time.
> 
> my 2 deprecated drachmas
> George
> 
> 
> 
> 
> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Thursday, February 07, 2002 1:24 PM
> To: 'George Tsirtsis'; Hesham Soliman (ERA)
> Cc: [email-masked]
> Subject: RE: RE: draft-ietf-pana-usage-scenarios-00.txt
> 
> 
> 
> 
> 
> > Who says that the DI is *access dependent*? 
> 
> => Not me !
> 
> It MAY be, 
>   > true, but it does not
>   > have to be. We currently only say that the DI MAY be 
>   > carried in PANA so it
>   > is not mandatory for a solution to do it. We also say that 
>   > the DI is a kind
>   > of handle that access control can use to authorize some 
>   > traffic. The DI
>   > could be as simple as an IP address or a link layer port 
>   > number if such
>   > thing is used in a given scenario but it could potentially 
>   > be other things
>   > as has been discussed.
> 
> => Phew... that's a relief. 
> FWIW I think we MUST specify who is being 
> authenticated/authorised. It is not enough to
> reserve a field in the protocol and say 'here
> you can carry whatever you like'. 
> Access independence is crucial here, so there is
> nothing wrong in saying that the DI (if you want to
> call it that) 'MUST NOT be access dependant' like 
> a MAC address for a certain link layer ...etc.
> You can have options to carry additional
> system dependant parameters (for tracking stolen
> devices perhaps) but they should be in addition
> to the generic identifier.
> 
> 
> 
> 
> Hesham
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 7 Feb 2002 19:20:41 -0800

Paal,

> "The functionality entities that comprise the PANA protocol include
discovery, message carrier, initial authentication, re-authentication and
disconnect. Each entitity should be specified as a module, with a clearly
defined interface to the other modules."

I don't think we need to say that. This goes without saying. It applies to
all protocol design, yet I don't see it called out in other requirements.

alper