Subject: [Capwap] comments to Pasi's opinion

From: young <[email-masked]>
Date: Fri, 22 Jan 2010 16:46:41 +0800

Hi, Pasi:

Thanks a lot. 
Please check my comment inline (identified by [Richard]).

Regards
Richard

-----邮件原件-----
发件人: Pasi Eronen [mailto:[email-masked]] 
发送时间: 2010年1月21日 18:07
收件人: [email-masked]
抄送: [email-masked];
[email-masked]
主题: DISCUSS: draft-ietf-capwap-base-mib

Discuss:
I have reviewed draft-ietf-capwap-base-mib-08, and have couple of
small questions that I'd like to discuss before recommending approval
of the document:

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

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

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

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

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

- 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).

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

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

Regards
Richard

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

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

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 15:18:50 +0100

> [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]

OK; please clarify the description accordingly.

> [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.

> You are correct. "dns"?should be removed.

OK.

>> WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6
>> Address" message element?
>
> [Richard]

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)

>> CapwapBaseWtpStateEntry? For example, whether NAT was detected, and
>> what the other address (depending on the question above) was?
>> [Richard]
>
> (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] 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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 25 Jan 2010 17:36:28 +0100

Comments on two of the points. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 

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

I do not remember this having been discussed. 

As now written the CapwapBaseWtpStateEntry presents the WTP information
whatever the topology is NAT-ed or not. This seems to me OK as a
starting point. What Pasi asks if I read correctly is to add columnar
object that describes whether the connection is NAT-ed and what is the
IP address visible from the AC. 

> 
> > >- capwapBaseMacAclId: this seems to limit the number of 
> ACL entries 
> > >to
> > [Richard] You are correct, it is not required to give a 
> scope limit to 
> > the capwapBaseMacAclId. The editors misunderstood the value 255 
> >> used by the CAPWAP protocol? (it doesn't seem to use the 
> zone index 
> >> in any way)
> >

I do not think it's supported, but I would suggest that the protocol
experts confirm this.