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

From: [email-masked]
Date: Fri, 29 Apr 2005 11:25:29 +0300

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

---

From: "Yoav Nir" <[email-masked]>
Date: Fri, 29 Apr 2005 15:02:13 +0300

I can try to give you a vendor's perspective. Most vendors implement the
internal addressing feature using some kind of virtual network adapter. This
can be a PPP adapter (as in Microsoft's L2TP) or a TUN/TAP adapter or a
virtual ethernet adapter or whatever. To the client-side operating system
they look like real network adapters.

When the client software brings up a network adapter (whether virtual or
physical), it has to be configured in several ways:
- IP address
- Netmask
- DNS servers associated with this interface
- NBNS servers (these days it's not just for Windows)
- interface-specific domain suffix
- routing changes

It's true that for VPN there's usually no point in the netmask attribute,
and it could safely be always set to 255.255.255.255, but the netmask is
always there.  We had a version where the netmask was always set to
255.255.255.0 (which just seemed the most standard), and customers
complained when they used different-sized networks for Cfg. We never could
get them to tell us why it was needed.

As for the INTERNAL_IP4_SUBNET, it just makes sense to use this as input for
the routing changes.  These will tell the operating system which traffic to
route through the virtual interface (and thus it gets encrypted) and which
traffic not to. If the SA does not cover the whole contents of the SUBNET
field, then subsequent packets will trigger more Create-Child-SA exchanges.

Certain small implementations of a gateway are the kind of small devices
that also serve as a DHCP server.  They assign IPs both to the internal
network and to remote-access clients, and they assign both from the same
pool.  These devices later work as bridges (rather than routers) and so the
NETMASK may matter.  If the client sends a broadcast packet, the device will
propagate it in the internal network (maybe also to all other clients?).  In
that case the client needs the NETMASK to properly form the broadcast
packets.  This may sound silly, but it can get protocols like the windows
file sharing protocol to work, allowing you to map network drives from the
road.  It has its uses.

----- Original Message ----- 

<snip>

Best regards,
Pasi