Subject: RE: [Ipsec] Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK

From: [email-masked]
Date: Fri, 6 May 2005 17:41:57 +0300

Hi Vijay,

Isn't that information already sent in INTERNAL_IP6_ADDRESS
attribute, in the "prefix length" field...?

Best regards,
Pasi

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, May 05, 2005 1:59 AM
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Ipsec] Clarifications open issue:
> INTERNAL_IP4_SUBNET/NETMASK
> 
> 
> hi Pasi,
> 
> I interpreted this in a different way for IPv6. IMO, the
> INTERNAL_IP6_SUBNET attribute should contain the prefix that
> corresponds to the IPv6 prefix from which the address
> returned in the INTERNAL_IP6_ADDRESS attribute is configured
> from.
> 
> Vijay
> 
> ps: we already had a discussion on this off list, but I thought
> it would be a good idea to get comments from others.
> 
> [email-masked] wrote:
> > Hi everyone,
> > 
> > One of the open issues in the IKEv2 clarifications draft
> > concerns INTERNAL_IP4_SUBNET and INTERNAL_IP4_NETMASK
> > attributes. We already had some discussion about these on the
> > list earlier, but I'd like to check if others think our
> > interpretation is roughly correct:
> > 
> > - INTERNAL_IP4_SUBNET in CFG_REPLY means roughly that "in
> >   my (responder's) opinion, you should send traffic to these
> >   addresses through me".  If these addresses are not included in
> >   TSr, obviously we need to create additional SAs.  And if TSr
> >   includes other addresses (e.g. is 0.0.0.0-255.255.255.255) 
> >   it means that the client can (but does not have to), if 
> >   permitted by its own policy, do "split tunneling" (only 
> >   send the traffic listed in INTERNAL_IP4_SUBNETs via the 
> >   gateway, but other traffic directly).
> > 
> > - Including INTERNAL_IP4_SUBNET in CFG_REQUEST is not 
> >   absolutely necessary: if the responder has this information, 
> >   it can send it anyway (as shown in the example in ikev2-17 
> >   Section 2.19). But if INTERNAL_IP4_SUBNET is included in 
> >   CFG_REQUEST, other lengths than zero don't make sense.
> > 
> > - The address blocks listed in INTERNAL_IP4_SUBNET do not have
> >   to match physical link boundaries. For instance, if the whole
> >   B class block 130.233.0.0/16 is behind the gateway, it's
> >   enough to send a single INTERNAL_IP4_SUBNET attribute (rather
> >   than listing all the /24s or whatever sized subnets that
> >   organization uses).
> >   
> > - INTERNAL_IP4_NETMASK does not make much sense, and should not
> >   be used (or it means the same thing as INTERNAL_IP4_SUBNET,
> >   and in that case, it's preferable to use INTERNAL_IP4_SUBNET).
> > 
> > draft-eronen-draft-eronen-ipsec-ikev2-clarifications-02.txt
> > actually has almost four pages of text about these payloads,
> > so especially if you disagree with our current opinion (which
> > is open to change, BTW), please check that, too!
> > 
> > Best regards,
> > Pasi
> > 
> > _______________________________________________
> > Ipsec mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipsec
> 
> 
> 

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 May 2005 13:15:57 +0300

> attribute, in the "prefix length" field...?

When the initiator requests IPv6 address with INTERNAL_IP6_ADDRESS, he
already fills that field with the hint what address he would like to
have.

If he had had address before then that address will be filled in
completely, as he would like to get same address back. If he has no
prefix to use, he can fill in the lower 64-bits to tell the server
which 64 lower bits to use for the address (i.e. fillin the interface
ID). The prefix length of the request most likely matches either the
previous prefix, or 64 in case initiator filled in lower 64 bits (or
prefix length matching the filled data).

When the responder (server) gets the request it first checks if the
address specified is acceptable, and if so it will return that.

If not he will replace the prefix length, and fill in the suitable
global routing prefix and subnet ID to be used for this connection.
Then it needs to check if the given IP-address is acceptable (i.e no
duplicate address already given out etc), and if so give it out.

If the address from previous step is not acceptable (for example
because the initiator didn't fill in the interface ID, and they are
all zeros), then the server will modify the interface ID so that it
forms acceptable IP-address.

> > returned in the INTERNAL_IP6_ADDRESS attribute is configured

I have not interpreted IKEv2 draft that way. INTERNAL_IP6_SUBNET is
specified to contain the "protected sub-networks that this edge-device
protects". That does not have anything to do with
INTERNAL_IP6_ADDRESS address allocation. Most commonly there is no
need to list the subnet where the address is allocated from in the
INTERNAL_IP6_SUBNET as it is already covered by the traffic selectors.
It could also be listed in the INTERNAL_IP6_SUBNET, but I do not think
that is necessary.
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 10 May 2005 17:43:49 -0700

Tero Kivinen wrote:
> completely, as he would like to get same address back. 

okay. this is my understanding too.

> If he has no

this can work, but is this specified anywhere in any spec?

> It could also be listed in the INTERNAL_IP6_SUBNET, but I do not think

okay. just wanted to see if my interpretation was correct.

another question. the prefix from which the address configured
through the INTERNAL_IP6_SUBNET is always part of the protected
sub-networks, right? so that prefix is always returned by the
responder?

Vijay