Re: [IPsec] Can one IPsec SA be established via two internet ports on one device?

[Paul Wouters]

On Mon, 19 Nov 2018, Linda Dunbar wrote:


When you said “IPs are sourced loopbacks that are part of a prefix exported to 
the the isp(s) in each site”,
do you mean that the private Loopback addresses of CPE1 & CPE2 are routable in 
all four  ISPs’ that
connected to A1, A2, B1, B2?


And to clarify, assuming your IPsec connection does not cover the IPs
used on both endpoints, but instead is some kind of subnet behind your
servers, then you can one IPsec SA. It does require some tricks if you
really want to limit it to one IPsec SA.

Remember that while you can choose which outgoing interface to use,
you cannot choose the incoming device, so it would be a poor load balance.

It is far easier to use two IPsec SA's that cover the same site-to-site
range.

On Linux, the easiest would be to setup two identical subnet-to-subnet
IPsec SA with a different XFRM mark. Then create a VTI device for each
of these. Then you can use routing and traffic shaping/control to send
packets to one or the other VTI interface for load balancing. If one of
the links goes down, the interface goes down and it all goes over the
remaining interace. Libreswan and strongswan support this. For
libreswan, use:

conn one
[basic config]
mark=8/0x
vti-interface=ispA
vti-routing=no
vti-shared=no
conn two
[basic config]
mark=7/0x
vti-interface=ispB
vti-routing=no
vti-shared=no

Then handle the routing/traffic control yourself.

Another solution for this is using MOBIKE, but then you are only using
one of the two in a failover type of scenario, and it is not doing any
kind of load balancing. Again libreswan and strongswan support this.

Paul

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

[IPsec] Adam Roach's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-ipsecme-split-dns-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/



--
COMMENT:
--

Thanks to everyone who worked on this document. It seems a very useful extension
to IKEv2. I have a handful of minor and editorial comments that you may want to
consider addressing.

---

Please expand "IKEv2" in the title and abstract. See
https://www.rfc-editor.org/materials/abbrev.expansion.txt for details.

---

§2.1:

>  To indicate support for Split DNS, an initiator includes one more
>  INTERNAL_DNS_DOMAIN attributes as defined in Section 3 as part of the
>  CFG_REQUEST payload.

I can't parse this. Is it mean to say "...one or more..."? Or is "attributes"
supposed to be "attribute"?

---

§2.1:

>  includes an INTERNAL_DNSSEC_TA attribute, but does not inclue an

Nit: "include"

---

§2.1:

>  An initiator MAY convey its current DNSSEC trust anchors for the
>  domain specified in the INTERNAL_DNS_DOMAIN attribute.  If it does
>  not wish to convey this information, it MUST use a length of 0.

As an implementor, I would have no idea whether this was something I wanted to
include. If it is configurable, then I would have no idea as an operator whether
how to set such configuration. Could we add some guidance here about when
implementations and/or operators might want to send this, and when they might
not?

---

§2.4.1:

>  The responder replies with two DNS server addresses, and two internal
>  domains, "example.com" and "city.other.com".

The domain "other.com" appears to be in active use by an organization known as
"Other Entertainment." Please consider using an example domain as described in
RFC 2606 section 2 or 3.

---

§2.4.2:

>  In this example, the initiator has no existing DNSSEC trust anchors
>  would the requested domain. the "example.com" dommain has DNSSEC

Nit: "...domain. The..."

---

§4:

>  For example, if the INTERNAL_DNS_DOMAIN attribute
>  specifies "example.com", then "example.com", "www.example.com" and
>  "mail.eng.example.com" MUST be resolved using the internal DNS
>  resolver(s), but "anotherexample.com" and "ample.com" SHOULD NOT be
>  resolved using the internal resolver and SHOULD use the system's
>  external DNS resolver(s).

The domain "anotherexample.com" is in use by a personal web site. The domain
"ample.com" is registered anonymously through Amazon.com. For this example that
needs to show a domain whose name is a subset of the indicated domain, please
consider using an example domain as described in RFC 2602 section 2.

---

§5:

>  DNS records can be used to publish specific records containing trust
>  anchors for applications.  The most common record type is the TLSA
>  record specified in [RFC6698].  This DNS record type publishes which
>  CA certificate or EE certificate to expect for a certain host name.

Please expand "CA" and "EE".

---

§5:

>  In most deployment scenario's, the IKE client has an expectation that

Nit: "scenarios"


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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03

[Rafa Marin Lopez]

Hi Paul:

First of all, thank you very much for this impressive review. We are going to 
process all your comments as soon as possible by separating our answers in 
different e-mails so that the discussion is easier to follow.

In any case, we would like to answer first to your initial question and Yoav's

> El 18 nov 2018, a las 7:52, Paul Wouters  escribió:
> 
> On Wed, 14 Nov 2018, Yoav Nir wrote:
> 
>> As discussed in the room, we need some reviewers for the 
>> sdn-ipsec-flow-protection draft ([1])
>> Thanks for these comments. Please see our response below.
>> While any comments on any part of the document are welcome, I would like 
>> people to concentrate on the following issues:
>> *  The YANG model in Appendix A
>> +  Some of the crypto seems obsolete (example: DES). We would get into 
>> trouble in SecDir review.  OTOH ChaCha20-Poly1305 is missing..
> 
> Based on the introduction and abstract of the draft, this document does two 
> things:
> 
> 1) Specify a yang model for use with SDWAN + IKE + IPsec
> 2) Define the desired modes and algorithms to use with 1)
> 
> It does not try to map the entire IKE/IPsec IANA registry into a yang model. 
> Let me know if this is incorrect, because I use
> this as an assumption for the remainder of the review.

We must say that our I-D specifies 1) but being SDWAN one of the possible 
scenarios to operate so that the intent was to map the IKE/IPsec IANA registry. 
In any case we can change that approach if the WG consider is the right way to 
proceed.

> 
>> The TLS working group went quite far with TLS 1.3.  Only 2 ciphers remain: 
>> AES-GCM with 16-byte ICV, and ChaCha20-Poly1305. That’s it.  Specifically, 
>> they’ve deprecated everything
>> that isn’t an AEAD.
> 
> I think this can work for this SDWAN use case as well. While I don't think 
> all systems
> are ready to support ChaCha20-Poly1305 for both IKE and ESP, I do believe all 
> systems
> used for SDWAN should be able to do AES-GCM with 16-byte ICV for IKE and ESP. 
> Although
> some IKE clients do not yet support AES-GCM for IKE (even while they support 
> it for ESP)
> 
>> The IPsecME working group hasn’t gone that far yet.  But in practice pretty 
>> much nothing is used except 3DES, AES-CBC, and AES-GCM.  Perhaps 
>> ChaCha20-Poly1305 is starting to see
>> some use by now. We have RFC 8221, especially sections 5 and 6.  I think 
>> (although it’s up to the working group) that we should be fine defining only 
>> the MUSTs and the SHOULDs in
>> those sections.
> 
> Yes, with the exception of ENCR_NULL for encryption and AUTH_HMAC_SHA1_96 for 
> integrity. (the latter is a MUST- only because of existing
> deployment, it is not recommended for new things)
> 
>> That brings another question. What is our plan for future expansions?  
>> Suppose there’s some hot, new algorithm that everyone is implementing. How 
>> do you update the YANG model in
>> the future when you add new values to the enumerations?  Is it up to the 
>> administrator to make sure that the controller and NSFs are all on the “same 
>> page”?
> 
> I'm wondering about that too, since it is basically a snapshot of the
> IANA registry SHOULD/MUST entries which changes over time.

This is really a good question. Most probably one better way would be import 
another yang model that we could use. In fact, there is an related effort in

https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02

that we could use. In any case, we will follow your advise here.

> 
> 
> 
> General comments:
> I'd like to see "Case 1" and "Case 2" replaced with more descriptive terms. I 
> keep losing track of which case is which.
> Perhaps call them IKE Case and IKE-less Case ?
> 
> 
> Section 1:
> 
>   Typically, traditional IPsec VPN concentrators and, in general,
>   entities (i.e. hosts or security gateways) supporting IKE/IPsec, must
>   be configured directly by the administrator.  This makes the IPsec
>   security association (SA) management difficult and generates a lack
>   of flexibility, specially if the number of security policies and SAs
>   to handle is high.
> 
> This is not entirely true. We have Opportunistic IPsec that automates
> this precisely for the same reasons. We also have packet triggers in
> combination with Traffic Selector narrowing to create multiple IPsec
> SA's on demand. I know this is all qualified by "typically" but I think
> this paragraph is not adding any real information. The idea is that we
> have an SDWAN situation with SDN controllers and nodes, and we want to
> automate the IKE/IPsec for that specific deployment use case.
> 
> 
>   The analysis of the host-to-gateway (roadwarrior) scenario is TBD.
> 
> Does this sentence mean this is to be done in this document or is it out
> of scope for this document (but it does allow it to be added later) ?
> 
> Section 3:
> 
> It requires information about the
> required authentication method (i.e. preshared keys), DH groups,
> modes and algorithms for IKE 

Re: [IPsec] Alexey Melnikov's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS)

[Alexey Melnikov]

Hi Paul,

On Mon, Nov 19, 2018, at 4:50 AM, Paul Wouters wrote:
> On 2018-11-18 12:40 a.m., Alexey Melnikov wrote:
> > --
> > DISCUSS:
> > --
> >
> > This is a well written document, so thank you for that.
> > I've noticed that Benjamin already found typos that I found and raised one 
> > of
> > the same questions, but I think this is important enough to be addressed 
> > before
> > I recommend approval of this document. Specifically:
> >
> > In Section 3.1:
> >
> > o  Domain Name (0 or more octets) - A Fully Qualified Domain Name
> >used for Split DNS rules, such as "example.com", in DNS
> >presentation format and optionally using IDNA [RFC5890] for
> >Internationalized Domain Names.
> >
> > Do you mean A-label or U-label form here?
> 
> 
> I thought it was obvious that we meant A-label. Why else refer to IDN if 
> you would just put in U-label, but I'll add the A-label term.

There are documents which allow either, so being clear on this point is 
important.

Thank you,
Alexey

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

[IPsec] Can one IPsec SA be established via two internet ports on one device?

[Linda Dunbar]

IPsec experts,

In the following diagram, CPE1 has two internet ports, A1 by one service 
provider, A2 by another service provider.
CPE2 also have two ports facing two different internet service providers

Question: can I establish ONE IPsec SA between CPE1 & CPE2? (i.e. between 
10.1.1.1 & 10.1.2.1)?
But the actual packets sent out from A1 port has to use A1 as Source-Address, 
and using B1 or other public address as Destination address.

Or is it necessary to have one IPsec SA between A1<->B1, one IPsec SA between 
A1<->B2, one IPsec SA between A2<->B1, and one IPsec SA between A2<->B2?


[cid:image001.png@01D4800A.7F9B4EE0]

Thanks, Linda Dunbar
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-split-dns-12

[Alissa Cooper]

Christer, thank you for your review. Tommy, thank you for addressing Christer’s 
comments. I entered a No Objection ballot.

Alissa


> On Oct 22, 2018, at 4:26 PM, Tommy Pauly  wrote:
> 
> Hi Christer,
> 
> Thanks again for the review. I've addressed all three comments below in an 
> update to the draft:
> 
> https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13 
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-13.txt 
> 
> 
> Thanks,
> Tommy 
> 
>> On Aug 19, 2018, at 1:39 PM, Christer Holmberg 
>> mailto:christer.holmb...@ericsson.com>> 
>> wrote:
>> 
>> Hi Tommy,
>> 
>> Please see inline.
>> 
>> 
>> Minor issues:
>> 
>> Q1:
>> 
 Section 3.1 contains some SHOULD-do statements, e.g.,:
 
 "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and
 INTERNAL_IP6_DNS attributes in the CFG_REQUEST"
 
 "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN 
 attributes
 in the CFG_REQUEST."
 
 Is there a reason for not using MUST instead of SHOULD?
>>> 
>>> In general, the CFG_REQUEST attributes are a bit loose—they're hints more 
>>> than requirements.
>>> 
>>> From section 3.15.1 of RFC7296:
>>> 
>>>  The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
>>>  information from its peer.  If an attribute in the CFG_REQUEST
>>>  Configuration payload is not zero-length, it is taken as a suggestion
>>>  for that attribute.  The CFG_REPLY Configuration payload MAY return
>>>  that value, or a new one.  It MAY also add new attributes and not
>>>  include some requested ones.  Unrecognized or unsupported attributes
>>>  MUST be ignored in both requests and responses.
>>> 
>>> So, the CFG_REPLY MUST have a DNS server to go along with the DNS domain, 
>>> but I left the SHOULD in spirit 
>>> of the fact that the CFG_REQUEST is more of a suggestion.
>>> 
>>> That being said, if others in the WG would like to see this be a MUST, I'm 
>>> fine with that as well. I don't think we 
>>> should have the responder error out if it doesn't see both, however.
>> 
>> Well, if it is only a suggestion, then I guess my question is why use 
>> something as strong as SHOULD :) SHOULD basically means 
>> MUST-unless-you-have-a-good-reason to.
>> 
>> In general, is providing suggestions a SHOULD, or is it only for the 
>> attributes above?
>> 
>> Anyway, if you want to have a SHOULD (or even a MUST) I won't object. But, 
>> when I see a SHOULD, I always ask about the background :)
>> 
>> 
>> Q2:
>> 
 Section 3.2 says:
 
 "the initiator SHOULD behave as if Split DNS configurations are not 
 supported
 by the server."
 
 Again, is there a reason for not using MUST?
>>> 
>>> This one could be a MUST. The one exception I could see is if the initiator 
>>> was statically configured with some split DNS domains to use as split 
>>> domains
>>> In case the responder didn't provide any in the CFG_REPLY, it should still 
>>> use those and not send all DNS queries inside the tunnel. I wouldn't want 
>>> this
>>> MUST to disable the static configuration workarounds that implementations 
>>> have done prior to allowing split DNS to be negotiated.
>> 
>> Could you say:
>> 
>> "the initiator MUST behave as if a Split DNS configurations are not 
>> supported, unless > above>"
>> 
>> 
>> 
>> Nits/editorial comments:
>> 
>> Q3:
>> 
 Is there a need for the "Background" section? Since the text is related to 
 what
 is described in the "Introduction", could the the text be moved there?
>>> 
>>> The main new points that the Background section adds on top of the 
>>> Introduction are:
>>> - The prior art for split DNS in IKEv1
>>> - The fact that this is currently mainly seen in enterprise VPN deployments
>>> 
>>> These points could indeed be moved to the introduction. I had felt they fit 
>>> better as "background" since they're 
>>> not essential to the description of the protocol, but give context that is 
>>> relevant now (and may be less so in the future).
>> 
>> The first sections of both the Introduction and the Background sections talk 
>> about split DNS:
>> 
>>   "Split DNS is a common configuration for secure tunnels, such as
>>   Virtual Private Networks in which host machines private to an
>>   organization can only be resolved using internal DNS resolvers"
>> 
>>   "Split DNS is a common configuration for enterprise VPN deployments,
>>   in which one or more private DNS domains are only accessible and
>>   resolvable via an IPsec based VPN connection."
>> 
>> So, isn't Split DNS already covered by the Introduction? What extra does the 
>> Background text bring?
>> 
>> The second paragraph of the Background could be placed at the end of the 
>> Introduction, in my opinion.
>> 
>> Regards,
>> 
>> Christer
>> 
>> ___
>> IPsec 

Re: [IPsec] Can one IPsec SA be established via two internet ports on one device?

[Linda Dunbar]

Joel,

Thanks for the help.

When you said “IPs are sourced loopbacks that are part of a prefix exported to 
the the isp(s) in each site”, do you mean that the private Loopback addresses 
of CPE1 & CPE2 are routable in all four  ISPs’ that connected to A1, A2, B1, B2?

Linda

From: joel jaeggli [mailto:joe...@gmail.com]
Sent: Monday, November 19, 2018 2:18 PM
To: Linda Dunbar 
Cc: IPsecME WG 
Subject: Re: [IPsec] Can one IPsec SA be established via two internet ports on 
one device?




On Nov 19, 2018, at 11:19, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:

IPsec experts,

In the following diagram, CPE1 has two internet ports, A1 by one service 
provider, A2 by another service provider.
CPE2 also have two ports facing two different internet service providers

Question: can I establish ONE IPsec SA between CPE1 & CPE2? (i.e. between 
10.1.1.1 & 10.1.2.1)?
But the actual packets sent out from A1 port has to use A1 as Source-Address, 
and using B1 or other public address as Destination address.


If in your example the source and destination IPs are sourced loopbacks that 
are part of a prefix exported to  the the isp(s) in each site then you could in 
fact have one association…

If the CPEs are using a provider assigned ip for tunnel termination  you’re 
going to need 4.

We do the former all the time with sites multi-homed via bgp.



Or is it necessary to have one IPsec SA between A1<->B1, one IPsec SA between 
A1<->B2, one IPsec SA between A2<->B1, and one IPsec SA between A2<->B2?




Thanks, Linda Dunbar
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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