> -----Original Message----- > From: Paul Wouters [mailto:p...@nohats.ca]
> >> I ran into this issue too when implementing. I realised that there is > >> really no reason for the server to ever act on what the client sends. > >> So I wondered if we should send it at all. It seems we might as well > >> not send anything to the server, and when the server gives us a list, > >> filter it based on what we will accept. This could be different based > >> on the kind of ipsec tunnel (corporate vs free proxy) > > > > > > [HJ] I think it is most flexible to still allow client to send what it > > want in CFG_REQUEST, but it is up to gateway's local policy to decide > > if it should consider or ignore them; For example, the > INTERNAL_DNS_DOMAIN could be used by gateway as additional hints for which > DNS server address to return in case a gateway is serving multiple types of > clients, each has its own internal domains to be resolved via its own DNS > sever; > Same applies to CFG_REPLY, it is up to client's local policy to decide > whether to > accept or ignore. > > I think though, that the server should return those attributes even if the > client > did not ask for them. I cannot think of a good example where the client > provided values would cause the server to return something different (as the > server should not trust the client to begin with) [HJ] I think Tero's example (company1 bought company2) make sense to me; there could be even case where the company1 wants to change the all domain names to company2, if we allow gateway to return different value, it will make such transition much easier; Just like today a client could send INTERNAL_IP4_ADDRESS in CFG_REQUEST to indicate its preference to get that address, but it doesn't mean gateway has to honor it; > > > In section 3.2, "If the CFG_REQUEST did not contain an > > INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an > > INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY." > > > > If it is agreed that it is essential local policy for what gateway > > send or accept, then gateway should be allowed to send > > INTERNAL_DNS_DOMAIN even when client doesn't include it in the > > CFG_REQUEST; > > But the assumption is, if the client does not support it, there is no point > in the > server sending it. > > I guess in the old IKEv1/ModeCfg we were more strict. You could not reply with > anything not requested. IKEv2 has relaxed this to say either side can send > anything and the other end just has to ignore what it does not understand. > [HJ] if client's doesn't support split DNS, of course it will not send these new CFG attributes, but I don't think we should always assume client doesn't support split DNS if it doesn't include these attributes in CFG_REQUEST > > According to section 2.19 of RFC7296, "the IRAS MAY also send other > > attributes that were not included in CP(CFG_REQUEST)", I think it is > > a general rule for all configuration attributes > > I guess I'm fine with either approach. Since the base IKEv2 RFC states any > side > can send/ignore anything, perhaps it is best to copy that approach in this > document as well? [HJ] I think we should just follow RFC7296 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
