On Mon, 13 Mar 2017, Hu, Jun (Nokia - US) wrote:

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)

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.

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?

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to