Skip to content
This repository has been archived by the owner on Oct 2, 2019. It is now read-only.

Support extended FLAGS for 'low-level' arbitrary control #56

Open
ytrezq opened this issue Nov 2, 2013 · 0 comments
Open

Support extended FLAGS for 'low-level' arbitrary control #56

ytrezq opened this issue Nov 2, 2013 · 0 comments

Comments

@ytrezq
Copy link

ytrezq commented Nov 2, 2013

In the case the browser listen on a port for incoming client connection, It would be nice to have the possibilities to refuse connections from certain IP addresses/hostname (blacklist). Which may be done with a .deny(list or table)
In the same way a white list for accepting a limited numbers of requests ( .allow(list or table) )

Or simpler, let know the hostname (trough revert DNS record) of the remote connection.

In this event, I think it would be nice to have an interface like this which could be coupled with the filters to chose the error to send (most firewalls propose TCP reset).
Of course, it could be used for other purposes.

interface TCPheader {
    unsigned int set_Sequence_number  // If some bits are missing:  Possible do bitmask  with the current default(rights) values.
    interface SendTCPflags {
        bool Send_NS
        bool Send_CWR
        bool Send_ECE // where With_FLAG_SYN=1 and Without_FLAG_SYN=0
        bool Send_URG
        bool Send_ACK
        bool Send_RST
        bool Send_SYN
        bool Send_FIN
    }
    unsigned short set_Urgent_Pointer If some bits are missing:  Possible do bitmask  with the current default(rights) values.
    interface options {
        // TODO complete this interface. I've no idea on what to put here since this header can have a variable length and you don't need to specify all options...
    }
}

Of course, I am not thinking at the other possibilities such as sending icmp_reponse, such as icmp-net-unreachable or icmp-host-prohibited since this API seems to only target UDP/TCP, Nor asking for the TCP KeepAlive feature.

I've also thought there's could be benefits for letting the user asking for explicit jubograms [de]activiation in the case of ipv6: it would allow sending more than 100ko of data in a single ip packets, and thus reduce (or avoid to do it for some kind of reason) the bandwidth.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant