[Capwap] Please check my comments,thanks

[shiyang 00338 <[e-mail]>]

Hi, Pasi:

Thanks.
Please check my comments under "///".
BTW, I am (have to) using web mail 
which may cause the format looks ugly. 

Sorry.

Regards
Richard

[e-mail] wrote:

>> - The MIB provides a writable object for switching between X.509 certs
>> and PSK authentication for DTLS.  Since the MIB can't actually
>> configure the PSK (or X.509 certificate and corresponding private key,
>> for that matter), is this object actually useful?

> [Richard] I think the configurations such as X.509 certificate
> belong to the configuration of DTLS protocol parameters, DTLS
> protocol should have (I don't know) a MIB corresponding to such
> function, I think such function is out of the scope of CAPWAP base
> MIB.  When operators do such function, he should operate DTLS' MIB.
> For this reason, Base MIB does not offer such interface.  The
> writable object in the Base MIB is only to let operator choose the
> DTLS Authentication policy from CAPWAP tunnel security
> perspective. This operation is from CAWPAP perspective, although
> this MIB object felt lonely in the Base MIB.

I'm still not sure the MIB object is useful. First of all, such DTLS
configuration MIB does not currently exist (and is not even
planned). Second, it hard-codes an assumption that all WTPs connected
to an AC use same type of authentication. The CAPWAP protocol itself
would allow some WTPs so use X.509 and others PSK, so if your AC
implementation supports this, it can't implement this MIB object.

BTW, the same limitation seems to apply to
e.g. capwapBaseDataChannelDTLSPolicyConfig, too -- if your AC supports
configuring DTLS for only some WTPs (perhaps those located in
physically less secure environments), it cannot implement this MIB
object.

If the WG feels this MIB object is anyway useful, at the very least it
should point out that many ACs may not be able to implement it.
////////////////////
[Richard]
Any way, the configuration of such authentication parameter should not be
in the scope of CAPWAP MIB (I explained it in the last email).
As per Pasi's comments, I agree to remove both  
capwapBaseControlChannelAuthenConfig and 
capwapBaseDataChannelDTLSPolicyConfig.

>> - It seems capwapBaseWtpState indicates the AC's CAPWAP FSM state
>> for each WTP, not the WTP's FSM? (which, at any single point of
>> time, be slighly different)
>
> [Richard]
> Yes, capwapBaseWtpState indicates the AC's CAPWAP FSM state for
> each WTP, not the WTP's FSM.  The capwapBaseWtpState is a MIB object
> on the AC.

OK; please clarify the description accordingly.
//////////
[Richard]
The description would be modified:
capwapBaseWtpStateTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF CapwapBaseWtpStateEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of objects that indicate the AC's CAPWAP FSM state
         for each WTP, and helps the operator to query the WTPs' current
         configuration."
    ::= { capwapBaseWtps 2 }

capwapBaseWtpStateEntry  OBJECT-TYPE
    SYNTAX      CapwapBaseWtpStateEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A set of objects that display the AC's CAPWAP FSM state
         for each WTP.
         Also, the operator could query the current configuration
         of a WTP by using the identifier of the corresponding
         WTP profile."
    INDEX { capwapBaseWtpStateWtpId }
    ::= { capwapBaseWtpStateTable 1 }

capwapBaseWtpStateEntry  OBJECT-TYPE
    SYNTAX      CapwapBaseWtpStateEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A set of objects that display the AC's CAPWAP FSM state
         for each WTP.
         Also, the operator could query the current configuration
         of a WTP by using the identifier of the corresponding
         WTP profile."
    INDEX { capwapBaseWtpStateWtpId }
    ::= { capwapBaseWtpStateTable 1 }
    
    capwapBaseWtpState  OBJECT-TYPE
    SYNTAX      INTEGER {
                  dtls(1),
                  join(2),
                  image(3),
                  configure(4),
                  dataCheck(5),
                  run(6),
                  reset(7),
                  dtlsTeardown(8),
                  unknown(9)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the various possible the AC's CAPWAP FSM state
         for each WTP.
         The following enumerated values are supported:
           dtls(1)         - DTLS negotiation states, which include
                             DTLS setup, authorize, DTLS connect
           join(2)         - The WTP is joining with the AC
           image(3)        - The WTP is downloading software
           configure(4)    - The WTP is getting configuration from
                             the AC
           dataCheck(5)    - The AC is waiting for the Data Channel Keep
                             Alive Packet
           run(6)          - The WTP enters the running state
           reset(7)        - The AC transmits a reset request message
                             to the WTP
           dtlsTeardown(8) - DTLS session is tear down
           unknown(9)      - Operator already prepared configuration
                             for the WTP, while the WTP has not contact
                             with the AC till now"
    REFERENCE
        "Section 2.3.1. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpStateEntry 5 }

The section 6 also needs change:
   4) capwapBaseWtpStateTable
   The WTPs status table is used to indicate the AC's CAPWAP FSM state
   for each WTP, and helps operator to query WTPs' current configuration.


> >- Section 9.1/9.2: it looks like these should be new CAPWAP Message
> >Element Types, not Vendor Specific Payloads? (and the current text
> >doesn't say what vendor ID would be used)
>
> [Richard] The Section 9.1/9.2 to let those CAPWAP variables
> manageable.  The messages are important.  Yes, the current text
> doesn't say what vendor ID would be used.  Could I put my company's
> ID (now it is H3C which belongs to 3com, would be HP soon since HP
> acquire 3com)? I don't know whether it is a acceptable way.  The
> vendor use their private ID could work, but not a good way.

This is not compatible with the way Vendor Specific Payloads are
defined in RFC 5415: unless the AC is from the same vendor (or
explicitly supports the other vendor's extensions), it cannot
know what Element ID value "1" means (or what the contents are).

Since these payloads are supposed to be work even when the AC and WTP
are from different vendors, they need to be normal message elements.
////////////////
[Richard]
What's CAPWAP WG opionion?

> > - Why is "dns" allowed as capwapBaseWtpStateWtpIpAddressType?  (the AC
> > obviously sees the IP address the WTP's connection comes from, but not
> > the DNS name?)
>
> [Richard]
> You are correct. "dns"?should be removed.

OK.

>> - capwapBaseWtpStateWtpIpAddressType: is this the IP address of the
>> WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6
>> Address" message element?
>
> [Richard]
> In case that a MIB object of InetAddress type is defined,
> one more MIB object of InetAddressType type is required.
> For this reason, the capwapBaseWtpStateWtpIpAddressType is defined.

This does not answer my question: is this the address as seen by the
AC, or the address sent in the message element? (which will be
different if the WTP is behind a NAT)
//////////////////////////
[Richard]
Should be the address sent in the message element. I would
give confirm after checking RFC5415 more.

>> - A question: Did the WG consider including NAT-related information
>> CapwapBaseWtpStateEntry? For example, whether NAT was detected, and
>> what the other address (depending on the question above) was?
>> [Richard]
>
> Yes, CAPWAP has NAT Considerations. But other tunnel protocol
> (suppose GRE or any other example) may also have such function.  I
> think there should have a generic MIB interface (no matter it exists
> or not) Which would offer NAT-related information, while such
> function is not A part of CAPWAP MIB (or other similar tunnel
> protocol).

I disagree. The NAT traversal functionality here is a functionality of
the CAPWAP protocol, and probably cannot be managed by any generic
MIB.

However, the question I asked was whether this was discussed
in the WG. Chairs, you do recall?
////////////
[Richard] 
Yes, it is valid to have such NAT info. 
I do fully agree. The question in my mind is how to design MIB to support such function.
For MIB design, I alway try to keep the MIB file short and reuse any existing MIBs. My initial point is that may could have a generic MIB for NAT function. I am not sure and want to ask: Anyone could you tell me whether it could have? Thanks.
I am ok to add such MIB objects in the CAPWAP MIB, but I really want to give a good design without any unnessary redundancy.

> >- capwapBaseMacAclId: this seems to limit the number of ACL entries to
> >255 -- why? (although RFC 5415 doesn't support sending more than 255
> >ACL entries in a single "Add MAC ACL Entry" message element, the AC
> >could send more than one of those)
>
> [Richard] You are correct, it is not required to give a scope limit
> to the capwapBaseMacAclId. The editors misunderstood the value 255
> mentioned in the RFC5415.

OK. 
////////////////
[Richard]
the change would be:
capwapBaseMacAclId OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Represents the unique identifier of an ACL."
    ::= { capwapBaseMacAclEntry 1 }

>> - capwapBaseWtpProfileWtpStaticIpType: How would the "ipv4z" type
>> be used by the CAPWAP protocol? (it doesn't seem to use the zone
>> index in any way)
>
> [Richard] In fact, I am not sure. Dan, Could you confirm whether
> CAPWAP support it?

OK; looking forward to hearing the answer...

Best regards,
Pasi





----- 原邮件 -----
从: [e-mail]
日期: 星期五, 一月 22日, 2010 下午10:18
主题: RE: comments to Pasi's opinion (draft-ietf-capwap-base-mib)

> [e-mail] wrote:
> 
> >> - The MIB provides a writable object for switching between 
> X.509 certs
> >> and PSK authentication for DTLS.  Since the MIB can't actually
> >> configure the PSK (or X.509 certificate and corresponding 
> private key,
> >> for that matter), is this object actually useful?
> 
> > [Richard] I think the configurations such as X.509 certificate
> > belong to the configuration of DTLS protocol parameters, DTLS
> > protocol should have (I don't know) a MIB corresponding to such
> > function, I think such function is out of the scope of CAPWAP base
> > MIB.  When operators do such function, he should operate DTLS' MIB.
> > For this reason, Base MIB does not offer such interface.  The
> > writable object in the Base MIB is only to let operator choose the
> > DTLS Authentication policy from CAPWAP tunnel security
> > perspective. This operation is from CAWPAP perspective, although
> > this MIB object felt lonely in the Base MIB.
> 
> I'm still not sure the MIB object is useful. First of all, such DTLS
> configuration MIB does not currently exist (and is not even
> planned). Second, it hard-codes an assumption that all WTPs connected
> to an AC use same type of authentication. The CAPWAP protocol itself
> would allow some WTPs so use X.509 and others PSK, so if your AC
> implementation supports this, it can't implement this MIB object.
> 
> BTW, the same limitation seems to apply to
> e.g. capwapBaseDataChannelDTLSPolicyConfig, too -- if your AC supports
> configuring DTLS for only some WTPs (perhaps those located in
> physically less secure environments), it cannot implement this MIB
> object. 
> 
> If the WG feels this MIB object is anyway useful, at the very 
> least it
> should point out that many ACs may not be able to implement it.
> 
> >> - It seems capwapBaseWtpState indicates the AC's CAPWAP FSM state
> >> for each WTP, not the WTP's FSM? (which, at any single point of
> >> time, be slighly different)
> >
> > [Richard]
> > Yes, capwapBaseWtpState indicates the AC's CAPWAP FSM state for
> > each WTP, not the WTP's FSM.  The capwapBaseWtpState is a MIB object
> > on the AC.
> 
> OK; please clarify the description accordingly.
> 
> > >- Section 9.1/9.2: it looks like these should be new CAPWAP Message
> > >Element Types, not Vendor Specific Payloads? (and the current text
> > >doesn't say what vendor ID would be used)
> >
> > [Richard] The Section 9.1/9.2 to let those CAPWAP variables
> > manageable.  The messages are important.  Yes, the current text
> > doesn't say what vendor ID would be used.  Could I put my company's
> > ID (now it is H3C which belongs to 3com, would be HP soon since HP
> > acquire 3com)? I don't know whether it is a acceptable way.  The
> > vendor use their private ID could work, but not a good way.
> 
> This is not compatible with the way Vendor Specific Payloads are
> defined in RFC 5415: unless the AC is from the same vendor (or
> explicitly supports the other vendor's extensions), it cannot
> know what Element ID value "1" means (or what the contents are).
> 
> Since these payloads are supposed to be work even when the AC and WTP
> are from different vendors, they need to be normal message elements.
> 
> > > - Why is "dns" allowed as capwapBaseWtpStateWtpIpAddressType?  
> (the AC
> > > obviously sees the IP address the WTP's connection comes from, 
> but not
> > > the DNS name?)
> >
> > [Richard]
> > You are correct. "dns"?should be removed.
> 
> OK.
> 
> >> - capwapBaseWtpStateWtpIpAddressType: is this the IP address of the
> >> WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6
> >> Address" message element?
> >
> > [Richard]
> > In case that a MIB object of InetAddress type is defined,
> > one more MIB object of InetAddressType type is required.
> > For this reason, the capwapBaseWtpStateWtpIpAddressType is defined.
> 
> This does not answer my question: is this the address as seen by the
> AC, or the address sent in the message element? (which will be
> different if the WTP is behind a NAT)
> 
> >> - A question: Did the WG consider including NAT-related information
> >> CapwapBaseWtpStateEntry? For example, whether NAT was detected, and
> >> what the other address (depending on the question above) was?
> >> [Richard]
> >
> > Yes, CAPWAP has NAT Considerations. But other tunnel protocol
> > (suppose GRE or any other example) may also have such function.  I
> > think there should have a generic MIB interface (no matter it exists
> > or not) Which would offer NAT-related information, while such
> > function is not A part of CAPWAP MIB (or other similar tunnel
> > protocol).
> 
> I disagree. The NAT traversal functionality here is a 
> functionality of
> the CAPWAP protocol, and probably cannot be managed by any generic
> MIB. 
> 
> However, the question I asked was whether this was discussed 
> in the WG. Chairs, you do recall?
> 
> > >- capwapBaseMacAclId: this seems to limit the number of ACL 
> entries to
> > >255 -- why? (although RFC 5415 doesn't support sending more 
> than 255
> > >ACL entries in a single "Add MAC ACL Entry" message element, 
> the AC
> > >could send more than one of those)
> >
> > [Richard] You are correct, it is not required to give a scope limit
> > to the capwapBaseMacAclId. The editors misunderstood the value 255
> > mentioned in the RFC5415.
> 
> OK.
> 
> >> - capwapBaseWtpProfileWtpStaticIpType: How would the "ipv4z" type
> >> be used by the CAPWAP protocol? (it doesn't seem to use the zone
> >> index in any way)
> >
> > [Richard] In fact, I am not sure. Dan, Could you confirm whether
> > CAPWAP support it?
> 
> OK; looking forward to hearing the answer...
> 
> Best regards,
> Pasi 
> 
> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap