How should we NAK an ADDRESS_REQUEST? about draft-ietf-masque-connect-ip HOT 5 CLOSED

It's also good because it doesn't have two ways of saying the same thing, since we'll need to handle 0.0.0.0/32 and ::/128 anyhow. I can try to write that up.

from draft-ietf-masque-connect-ip.

Thanks for filing this @asedeno. I agree that the draft isn't currently clear enough on how to respond to these scenarios. The three options I see are:

1. do nothing
2. write some text to explain how to use the existing capsule formats to indicate a rejected address request
3. add a list of rejected request IDs to the ADDRESS_ASSIGN capsule

Of these I think we really should avoid (1) because that could lead to interoperability issues, but I'm ok with either (2) or (3). I think I prefer (3) because changing the wire format now isn't too high of a cost and I think it'll make the protocol more explicit.

from draft-ietf-masque-connect-ip.

I agree we should do something here. Between (2) and (3), I'm not sure.

We could fairly easily just say that if you include an Assigned Address with a non-zero Request ID but the assigned address is all zeros with a prefix length of 32 or 128, you're assigning an empty address, which is a rejection. Arguably, client must handle receiving such a capsule response anyway, and treat it as "no address assigned for that request". This is option (2), I think.

If we do something like option (3), we'd have a field in the main ADDRESS_ASSIGN capsule for a list of rejected IDs, which would likely need to have a length in front, so we'd now have a field of at least a byte in all ADDRESS_ASSIGN capsules (even ones with no rejections) to handle the possibility of rejections.

We either have a case where a lot of rejections leads to a somewhat bloated capsule, but the happy cases are nice and concise, or a case that optimizes for lots of rejections and always adds a byte to the happy cases. I personally prefer (2) there, since it only gets ugly if a ton of requests are being made anyhow.

Thoughts @DavidSchinazi ?

from draft-ietf-masque-connect-ip.

I like your proposal @tfpauly, if we add text saying that 0.0.0.0/32 and ::/128 mean "your request was rejected" then we get the explicit property without changing the wire format. That works for me.

from draft-ietf-masque-connect-ip.

I appreciate the added symmetry that comes from giving the zero addresses specific meaning in both requests and assignments, and no wire format changes + no ambiguity is a win. LGTM.

from draft-ietf-masque-connect-ip.