|
David, I have a concern related to the Session ID. This is specified re: Session-ID: Any change in this value between ICMP messages MUST be considered by the client to mean a change in access policy has occurred and previous notifications are no longer valid. One problem with this is that different network elements may be competing with policy for the same end-point, thrashing each other’s policy. E.g., one network element could be informing about quota and another could be informing about a weather warning. (Or one of these might not be legitimate.) A fix for this is to put the Session-ID in the context of the IP address of the host sending the ICMP message. NEW: Any change in this value between ICMP messages from the same source IP address MUST be considered by the client to mean a change in access policy has occurred and previous notifications are no longer valid. From: David Bird [mailto:[email protected]]
I've updated the I-D here https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach, comments appreciated. The Policy Class 'hint' can be any value that both the NAS and CP understand. Not all implementations will use it; it is only really useful if your NAS might send users to the CP for one of several reasons. A very simple use-case could
be that the NAS puts the destination port in the Policy Class so that the CP knows what services you were trying to access. On Wed, Aug 31, 2016 at 2:00 PM, Dave Dolson <[email protected]> wrote: David, Yes, I would like to see that draft updated, thanks. Would this new hint support different reasons? E.g., bad weather warning vs. payment required? -Dave From: David Bird [mailto:[email protected]]
I am working updating
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I plan to add a 'policy class' uint32 to the ICMP message that can be used as a site specific 'hint' to the captive portal. This uint32 is site specific and -can- be unique per visitor and
should only be used by portal as a hint/reason (capport URL gotten from DHCP rfc 7710) . On Aug 31, 2016 5:55 AM, "Dave Dolson" <[email protected]> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled off. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
This will be more real-time than relying on the sender to periodically probe well-known servers on port 80.
Such a message should indicate a reason, which could be a URL to a JSON/REST interface.
Or, it could simply be an event that means "go probe port 80 to get redirected"
I believe ICMP is useful for realtime, 5-tuple flow specific (as well as general), notifications, but it should not be used to carry any session parameters or meaningful data. A
REST API would be better for that. On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe <[email protected]> wrote: I am looking at the mechanisms to communicate captive portal states to |