Subject: Re: [Nea] Comments on draft -04

From: <[email-masked]>
Date: Fri, 21 Sep 2007 16:45:54 -0700

Hi Yaron and Kaushik, 

I have a couple comments, inline regarding the PA protocol opacity with PB.

[snipped] 

> 
> > * PA-5 (security of PA protocol): security at this level is
> probably
> > infeasible, especially if PB entities should be able to
> intercept PA
> > messages (not just to mux and demux them). This is also
> related to the
> > comment above regarding 1:1 correspondence between PC and PV.
> 
> <Kaushik> I am not sure that PA-5 implies that all of the PA data will 
> enveloped; PA security must ensure that there is enough data in the 
> clear to allow for the PB layer to appropriately route the attribute 
> messages. There is also another thread on the WG mailing list that 
> questions whether PA security needs to be a MUST, do you have any 
> input to that discussion ?
> </Kaushik>
> 

<Gary>
PB-2 states PA data must be opaque to the PB protocol.  Is there a need for PB to inspect PA data?  I don't know of any and think addressing is a property of the interface between a PV/PB Server or PC/PB Client respectively.  Please refer to my subsequent comment regarding addressing for rationale of this assertion.
</Gary>

[snipped]

> 
> 
> > * PA-*: there is also addressing at this level, why are there no 
> > related requirements? PA requirements should not be
> relegated to the PB section.
> > *
> <Kaushik> We did not want to specify normative schemes for 
> addressing/identification at the PA layer in the requirements document 
> since it might be better to address that in PA protocol design. We do 
> have text in the reference model that provides guidance to protocol 
> design. Here is the text I am referring to ³Each Posture Validator 
> will be associated with one or more  identifiers that enable it to be 
> the specified as the  destination in a PA message.  The Posture Broker 
> Server uses  this identifier to route messages to this Validator.  
> This  identifier might be dynamic (e.g.
> generated by the Posture   Broker Server at run-time during 
> registration) or
> more static   (e.g. pre-assigned to a Posture Validator at 
> install-time and
> passed to the Posture Broker Server during registration) or a 
>   function of
> the attribute messages the validator desires to  receive (e.g. message 
> type for subscription). </Kaushik>
> 
> 

<Gary>
There is much precedence in the IETF to place routing information not in
the payload but rather in the encapsulating protocol and convey routing information
via the interface to the encapsulating protocol.  A couple of examples are with TCP 
and IP. An application utilizing TCP doesn't place the port numbers in its payload for
TCP to discover but rather coveys this in the interface.  The same holds true with the
TCP to IP interface in which protocol ID and IP addresses conveyed. With respect to
PB Identifiers, I assumed the PVs and PCs would be conveying them to PB via out of scope
interfaces.

As to local node scope dynamic assignment, I don't see how that would work for PB
Identifiers as I assumed these would be used for addressing purposes in both directions
(PV->PC) and (PC->PV) and would be assigned by some central authority, like say IANA.  
</Gary>

[snipped]

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea