Re: [IPsec] [ipsecme] #217: Temporary credentials

[Tero Kivinen]

Geoffrey Huang writes:
> It's starting to sound like existing methods, to be sure.  I'm skeptical
> of introducing yet another form of authentication.  This would add to the
> complexity of the overall system.  To frame it in terms of a requirement,
> I propose that any leaf-to-leaf communication has to be done with existing
> (already defined) authentication methods: for instance, either
> certificates or pre shared key.

Yes, we do want to use existing authentication methods. The question
is can we use existing credentials. We cannot securely reuse existing
pre-shared keys, as that would require sharing keys between peers who
normally do not share keys. We cannot easily reuse EAP crendentials,
as most of the leafs (especially the road warrior cases) do not have
trust relationship with the EAP server, so they cannot verify other
ends EAP credentials.

We can reuse existing certificates and public/private key pairs, but
if any other authentication methods are needed, we need to provide
solution how peers can get some kind of temporary credentials they can
use with the existing authentication methods to authenticate them to
another peer. For that the private/public key pair (with or without
certificates) is the most convinient one.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #217: Temporary credentials

[Geoffrey Huang]

It's starting to sound like existing methods, to be sure.  I'm skeptical
of introducing yet another form of authentication.  This would add to the
complexity of the overall system.  To frame it in terms of a requirement,
I propose that any leaf-to-leaf communication has to be done with existing
(already defined) authentication methods: for instance, either
certificates or pre shared key.

-geoff

On 3/26/12 1:07 AM, "Yoav Nir"  wrote:

>
>On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote:
>
>> 
>>> "Geoffrey" == Geoffrey Huang  writes:
>>Geoffrey> My initial inclination is to say that won't fly: that many
>>Geoffrey> deployments still require preshared key authentication.
>>Geoffrey> Rather, they would object to certificates because of
>>Geoffrey> perceived complexity. That said, I could see arguments
>>Geoffrey> that what we're discussing are already fairly
>>Geoffrey> sophisticated topologies, so perhaps the certificate
>>Geoffrey> allergy doesn't hold?
>> 
>> Tero isn't proposing using certificates.
>> 
>> Tero is proposing that the gateway/hub provides each leaf node with a
>> gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs
>> of identity.  It would be used only for the leaf to leaf connection.
>> It would be retained for a convenient period of time and then destroyed.
>
>Not just leaf-to-leaf, but also leaf to any other node, even if it's not
>a real leaf.
>
>This is beginning to look a lot like Kerberos, no?
>
>Yoav
>
>___
>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

Re: [IPsec] draft-nir-ipsecme-erx

[Yoav Nir]

On Mar 26, 2012, at 6:43 PM, Tero Kivinen wrote:

> Yoav Nir writes:
>> This is about my presentation from the IPsecME meeting today (which
>> for some reason is not on the website) 
>> 
>> Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry
>> ERP messages". This caused some controversy a year ago, but
>> regardless, I did think of a use case, so I partnered with Qin Wu
>> and wrote the draft. 
> 
> RFC5996 says:
> 
>   While this document references [EAP] with the intent that new methods
>   can be added in the future without updating this specification, some
>   simpler variations are documented here.  [EAP] defines an
>   authentication protocol requiring a variable number of messages.
> 
> and
> 
> A short summary of the EAP format is included here
>   for clarity.
> 
> So my take there is that the EAP description in the RFC5996 is just
> for clarity, and is not meant to be exhaustive, meaning it does not
> limit codes we can use in the EAP messages. 

Agree. That's why my draft calls it "clarification"

> 
> On the other hand RFC5996 also says that:
> 
>   Following such an extended exchange, the EAP AUTH payloads MUST be
>   included in the two messages following the one containing the EAP
>   Success message.
> 
> which means that as ERX uses different message to finish the
> authentication, update to the RFC5996 is needed (i.e. not to allow
> codes 5 and 6, but to say we can have EAP payloads in exchanges where
> they normally do not be and tell that EAP exchange can finish with
> these other codes too).
> 
>> My first priority is for this to become a WG item. It probably needs
>> some work, and there is an open question about whether there is any
>> use case for multiple AAA domains. 
> 
> I agree it could be WG item. On the other hand I also think it might
> be quite fast document, so getting it out as individual rfc might be
> faster.

They're not necessarily faster. What the draft needs is review, especially 
regarding the assumption that multiple AAA domains are not needed. I think WG 
documents get better review, but even that is not really clear.

Yoav

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

[IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

As described in the IPsecME WG meeting I propose that we change the
registration policy for the IPSEC Authentication Methods (Value 3) of
ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From
RFC5226):

--
  IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.

To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.

Examples: IPSECKEY Algorithm Types [RFC4025],
Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
Handshake Hello Extensions [RFC4366].
--

I will ask IANA to make the change at the 2012-04-15, unless I get
some objections here in the list. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] draft-nir-ipsecme-erx

[Tero Kivinen]

Yoav Nir writes:
> This is about my presentation from the IPsecME meeting today (which
> for some reason is not on the website) 
> 
> Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry
> ERP messages". This caused some controversy a year ago, but
> regardless, I did think of a use case, so I partnered with Qin Wu
> and wrote the draft. 

RFC5996 says:

   While this document references [EAP] with the intent that new methods
   can be added in the future without updating this specification, some
   simpler variations are documented here.  [EAP] defines an
   authentication protocol requiring a variable number of messages.

and

 A short summary of the EAP format is included here
   for clarity.

So my take there is that the EAP description in the RFC5996 is just
for clarity, and is not meant to be exhaustive, meaning it does not
limit codes we can use in the EAP messages. 

On the other hand RFC5996 also says that:

   Following such an extended exchange, the EAP AUTH payloads MUST be
   included in the two messages following the one containing the EAP
   Success message.

which means that as ERX uses different message to finish the
authentication, update to the RFC5996 is needed (i.e. not to allow
codes 5 and 6, but to say we can have EAP payloads in exchanges where
they normally do not be and tell that EAP exchange can finish with
these other codes too).

> My first priority is for this to become a WG item. It probably needs
> some work, and there is an open question about whether there is any
> use case for multiple AAA domains. 

I agree it could be WG item. On the other hand I also think it might
be quite fast document, so getting it out as individual rfc might be
faster.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] draft-nir-ipsecme-erx

[Yoav Nir]

Hi

This is about my presentation from the IPsecME meeting today (which for some 
reason is not on the website)

Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry ERP 
messages". This caused some controversy a year ago, but regardless, I did think 
of a use case, so I partnered with Qin Wu and wrote the draft.

The use case is being able to seamlessly move between two networks were network 
access is granted or denied based on EAP. Examples are 802.1x and IKEv2. IEEE 
has already revised 802.1x so that moving between two 802.1x access points can 
use ERP to be seamless, but IKEv2 has not. a mobile device could use 802.1x 
within the corporate network and move to IPsec as soon as it leaves the 
building. MCR has called this the "Elvis" use case, but it actually should work 
seamlessly in the other direction, when the mobile node enters the building, 
detects the 802.1x network, establishes an association, and deletes the 
no-longer-needed IKE and child SAs.

My first priority is for this to become a WG item. It probably needs some work, 
and there is an open question about whether there is any use case for multiple 
AAA domains.

If not, I'm also fine with taking this directly to Sean.

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

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

[Tero Kivinen]

Daniel Migault writes:
> My understanding is that there are two things, that may be considered
> independently:
> - configuring IPsec layer
> - defining which route the communication should take
> 
> I don't understand why only one tunnel should be used. A mobile node, when
> it detects a new interface, should be able to "add" this Interface on the
> already existing tunnel. It looks to me as a limitation of MOBIKE. * This
> would would allow the mobile node to use multiple tunnels. Which tunnel to
> choose depends on other inputs. The important thing is that the mobile can
> can use multiple tunnels. **
> 
> 
> * "adding" could mean deriving a new SA from the old tunnel. This important
> thing here seems to avoid re-doing an IKE exchange.

MOBIKE already does that. I.e. when it detects another interface
(IP-address) it will send ADDITIINAL_IP{4,6}_ADDRESS notifications and
then new IP-addess is also one of the address which can be used. With
MOBIKE we still only use one address, but we can change which address
we use easily.

On the other hand I do not think MOBIKE is really applicable in this
case, as I think in most of the cases the tunnel end points are NOT
going to be same. I.e. we do not try to create multiple tunnels
between same endpoints, but create multiple tunnels between different
endpoints, and in that case MOBIKE cannot be used. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Michael Richardson]

<#part sign=pgpmime>

Actually, in my haste, I skipped a possible step:

step1, H1 tells A that H2 is closer:

  AB
   \  /
\.   /
 \\ /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


step2, H2 tells A where H3 is:

  AB
   \  /
\.  \/
 \\  \  /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD

step3, H3 tells A where B is:

  AB
   \  /
\.  \/
 \\  \  /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

[Daniel Migault]

My understanding is that there are two things, that may be considered
independently:
- configuring IPsec layer
- defining which route the communication should take

I don't understand why only one tunnel should be used. A mobile node, when
it detects a new interface, should be able to "add" this Interface on the
already existing tunnel. It looks to me as a limitation of MOBIKE. * This
would would allow the mobile node to use multiple tunnels. Which tunnel to
choose depends on other inputs. The important thing is that the mobile can
can use multiple tunnels. **


* "adding" could mean deriving a new SA from the old tunnel. This important
thing here seems to avoid re-doing an IKE exchange.

** this would require that SPD-O is derived per interface. Since a single
SPD is ordered and will always provide the same first match. I am not sure
how that can be implemented and would appreciate feed backs on that point.

Regards,

Daniel


On Mon, Mar 26, 2012 at 11:04 AM, Michael Richardson
wrote:

>
> > "Vishwas" == Vishwas Manral  writes:
>Vishwas> Branch routers have 3G/ 4G interfaces as backups for the
>Vishwas> primary interface
>Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired
>Vishwas> interface at
>Vishwas> all to the backend.
>
> Vishwas, it's not about requirements on immobile branch offices, or
> *they* connect to the internet.
>
> It's about laptops/smartphones which are typically "remote" on various
> interfaces (including 3G and wifi going up/down regularly), and what
> happens when such a device is now *inside* a branch office.
>
> (A laptop with an ethernet is more likely to be 'inside' the branch
> office than a laptop/smartphone with wifi at the office, depending
> whether the WIFI is bridged to LAN, or the wifi is considered untrusted)
>
> How does this device learn that it should now rely in the branch
> office's MESH membership, rather than it's own MESH membership?
>
> I don't think that the title of this ticket is well chosen.
> I can do a diagram.
>
>
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>


-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem.

[Vishwas Manral]

I agree.

-Vishwas

On Mon, Mar 26, 2012 at 1:12 AM, Michael Richardson
wrote:

>
> I agree: it's not a "hard problem". It's an annoying problem, and the
> lack of a dynamic solution causes poor experiences for users.
>
> For a relatively static group of non-moving leaf gateways, even a very
> large group, a bit of scripting could generate most of the full mesh
> policy, and normal IKEv2 on-demand keying of links would bring up
> tunnels as needed.
>
> The reason to have an automatic system is because:
>1) we have mobile nodes that we want to include (roadwarriors)
>
>2) we have gateways behind NAT that can be hard to find.
>
>3) we have machines/gateways that have non-transtive authentication
>   mechanisms, and it would be very annoying to setup each leaf
>   system with a trusted connection to the AAA system for
>   authentication.
>
> --
> ]   He who is tired of Weird Al is tired of life!   |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video 
>   then sign the petition.
>
>
> ___
> 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

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Michael Richardson]

> "Yoav" == Yoav Nir  writes:
>> You didn't take my comments too far; I think you realized that I was in
>> fact saying two things:
>> 
>> 1) when traffic is redirected, MUST it be redirected directly to the
>> real endpoint?  (There might be issues of in-band double NAT that

>> 2) when traffic is redirected, MAY it be redirected more than once?

Yoav> Aren't these really the same question?  

case1: Q1:yes, Q2: yes.  
   Must redirect to final end point, but it is okay for redirection
   to occur multiple times.  This implies that when A is redirected
   to H2, that no SA is created with H2, but rather there is an
   immediate redirection to H3, and again to B.

case2: Q1:yes, Q2: no
   Must redirect to final end point, but redirection not permitted.
   H1 must get address of B via "magic" and tell A about it.

case3: Q1:no, Q2: yes.
   final end point not required, multiple redirection.
   H1 can redirect to H2.  A sends traffic to H2.
   H2 can decide to send a new redirect to H3 based upon seeing
   what traffic is arriving.  
   (Note that B might get redirected by H2 for traffic for A to H2,
   and now we have A<-->H2<-->B, and now H2 actually knows about 
   both A and B, and either easily link them directly, or realize
   that neither are directly reachable, and since H2 has plentiful
   bandwidth, it doesn't care...)

case4: Q1:no, Q2: no.
   H1 should either redirect to B directly, or can redirect to
   H3, but H1 has to know whether or not B is directly reachable.
   At the same time, H3 might be redirecting B to H1 if A is not 
   reachable, and we might have asymmetric routing.  
   This might screw the SPD on A and B if your SPD is strict 4301.

Yoav> IOW it should be a requirement that H1 (in the diagram of your
Yoav> previous mail) be able to send more information about the
Yoav> topology behind H2 than just "B is behind H2", such as "D and
Yoav> H3 are also behind H2". But A should be required to not expect
Yoav> it. 

Yoav> So H1 MUST be able to tell A that B is behind H2. It MAY be
Yoav> able to tell A that D is also behind H2, or that B is actually
Yoav> behind H3, or the actual address of B. 

So, you just created a requirement for H1<->H2 communication :-)



pgpy386mRbhY6.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-00.txt

[Daniel Migault]

I also support the draft
Daniel

On Tue, Mar 6, 2012 at 5:37 AM, Paul Hoffman  wrote:

> On Mar 5, 2012, at 3:26 AM, Tero Kivinen wrote:
>
> > I just posted following document. I think I would like to get few
> > minutes in Paris to explain this document, and see wheter there is any
> > comments to it. I think it should be forwarded as individual draft to
> > the RFC, but I am not sure whether it should be informational or
> > standards track document, and this is something I would like to get
> > feedback from the community.
>
> I see no reason it should not be on standards track.
>
> > This is very similar in ideas than to the tls version
> > (draft-ietf-tls-oob-pubkey-01), i.e. it shares the same format for the
> > raw key.
>
> And this is good.
>
> --Paul Hoffman
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Yoav Nir]

On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote:

> 
>> "Yaron" == Yaron Sheffer  writes:
>Yaron> I don't want to speak for MCR, but I think you are taking his
>Yaron> question too far towards the implementation aspects. What I
>Yaron> read in the question is, do we allow for a situation where
>Yaron> (by policy and/or because of limitations in the solution) an
>Yaron> endpoint cannot connect directly to the ultimate peer, but
>Yaron> needs instead to go through some sort of relay.
> 
> You didn't take my comments too far; I think you realized that I was in
> fact saying two things:
> 
> 1) when traffic is redirected, MUST it be redirected directly to the
>   real endpoint?  (There might be issues of in-band double NAT that
>   matter if the traffic doesn't get all the way there... I dunno, IPv6
>   RFC6145 is my answer to double NAT)
> 
> 2) when traffic is redirected, MAY it be redirected more than once?

Aren't these really the same question?  

My answer is that it's OK for redirection to happen more than once, but it's 
better to have less redirections than more.

IOW it should be a requirement that H1 (in the diagram of your previous mail) 
be able to send more information about the topology behind H2 than just "B is 
behind H2", such as "D and H3 are also behind H2". But A should be required to 
not expect it.

So H1 MUST be able to tell A that B is behind H2. It MAY be able to tell A that 
D is also behind H2, or that B is actually behind H3, or the actual address of 
B.

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

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

[Michael Richardson]

> "Vishwas" == Vishwas Manral  writes:
Vishwas> Branch routers have 3G/ 4G interfaces as backups for the
Vishwas> primary interface 
Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired
Vishwas> interface at 
Vishwas> all to the backend.

Vishwas, it's not about requirements on immobile branch offices, or
*they* connect to the internet.

It's about laptops/smartphones which are typically "remote" on various
interfaces (including 3G and wifi going up/down regularly), and what
happens when such a device is now *inside* a branch office.

(A laptop with an ethernet is more likely to be 'inside' the branch
office than a laptop/smartphone with wifi at the office, depending
whether the WIFI is bridged to LAN, or the wifi is considered untrusted)

How does this device learn that it should now rely in the branch
office's MESH membership, rather than it's own MESH membership?

I don't think that the title of this ticket is well chosen.
I can do a diagram.





pgpfStzTrqw6G.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

[Michael Richardson]

I think that whenever a node moves from the point of view of it's
"primary" connection, that it should tear down all "auxiliary" tunnels.

Due to the movement of the node, it may be impossible to communicate
with the end-points of the auxiliary tunnels (due to NAT restricted-cone
at one end or the other), so we will need a way to send tear down
notices (and/or I've moved notices) via the "hub" systems.  

There are many ways to do this (various ways inside IKEv2, via IP
routing...), but it's really important that the auxiliary tunnels for
"A" get destroyed on node "B" when "A" moves, reboots, updates it's NAT
address, etc.

This is not exclusively about MOBIKE: there are lots of other ways in
which the A<-->H1 connection can change which would affect "B".

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgprff6r0qEb9.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #215: Should traffic flow through the gateway while a shortcut is being established?

[Michael Richardson]

> "Stephen" == Stephen Hanna  writes:
Stephen> #215: Should traffic flow through the gateway while a
Stephen> shortcut is being 
Stephen> established?

Yes.
No traffic should be delayed or dropped if it can be delivered.
This entire system is an optional *optimization*!  

It may be *required* in order to get a sufficiently high quality path
for some services (VoIP), but, from a layer-3 point of view, it's
optional.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgpZR0Nw4lffE.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Michael Richardson]

> "Yaron" == Yaron Sheffer  writes:
Yaron> I don't want to speak for MCR, but I think you are taking his
Yaron> question too far towards the implementation aspects. What I
Yaron> read in the question is, do we allow for a situation where
Yaron> (by policy and/or because of limitations in the solution) an
Yaron> endpoint cannot connect directly to the ultimate peer, but
Yaron> needs instead to go through some sort of relay.

You didn't take my comments too far; I think you realized that I was in
fact saying two things:

1) when traffic is redirected, MUST it be redirected directly to the
   real endpoint?  (There might be issues of in-band double NAT that
   matter if the traffic doesn't get all the way there... I dunno, IPv6
   RFC6145 is my answer to double NAT)

2) when traffic is redirected, MAY it be redirected more than once?

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 




pgphB2ZfurJj1.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Michael Richardson]

{fat fingers let previous email got away too soon, ignore}

> "Stephen" == Stephen Hanna  writes:
Stephen> I think that Michael is asking an important question. There
Stephen> are many ways to solve the P2P VPN problem. One way is to
Stephen> have satellites with little configuration that connect to
Stephen> core gateways with lots of dynamic information. A core
Stephen> gateway (a "hub" in Michael's parlance) can download things
Stephen> to a satellite (maybe a new SPD and PAD, credentials,
Stephen> etc.), thus causing some traffic from the satellite to be
Stephen> sent to a different core gateway or satellite. In that
Stephen> circumstance, I think Michael's question is about whether
Stephen> the core gateway that a satellite initially connects (which
Stephen> I'll call the "initial core gateway") to should be expected
Stephen> to have or obtain all the information needed to configure
Stephen> the satellite or whether the initial core gateway can send
Stephen> the satellite to another core gateway where it can get more
Stephen> information. At least, that's how I understand Michael's
Stephen> question. Perhaps he can affirm or deny this
Stephen> interpretation.

You got my question correctly.

I'm gonna add a diagram so that everyone can agree.  (Those of you with
mailers that ignore text/plain; format=fixed, you need to copy this
email to Wordpad/vi, or it will be munged by your RFC-ignorant
vendor. Oh, I'll paste it into the ticket too)

In the requirements document, I think that we need establish some
nomenclature, such as "hub".  and "initial hub", or "core", as you wish.

Given that goal of this is to go from hub+spoke (generalized to
trunk+feeder.. In my spare time I'm actually a transit expert. True story)


  AB
   \  /
\/
 \  /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


Leaf A has traffic of leaf B.  It would otherwise go via Hub1(H1), Hub2,
and Hub3.

Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol,
magic will happen.  The question, *AT THE REQUIREMENTS* phase, is
whether a solution such as:

step1, H1 tells A that H2 is closer:

  AB
   \. /
\\   /
 \\ /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


step2, H2 tells A where B is:

  AB
   \. /
\\   /
 \\ /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


open question whether when H1 told A about H2, whether it in fact told 
A about *all* of the topology that H1 knew about H2, or just about A.
Would traffic from A to D go via H2 after step1, or would traffic to D
continue to go via H1/H2?

This speaks to requirements, because if H1 needs to know where B is,
then we need to have a protocol along trunk1 and trunk2 that permits the
information about where B is to be communicated.  

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 


pgp001BO8okTD.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Michael Richardson]

> "Stephen" == Stephen Hanna  writes:
Stephen> I think that Michael is asking an important question. There
Stephen> are many ways to solve the P2P VPN problem. One way is to
Stephen> have satellites with little configuration that connect to
Stephen> core gateways with lots of dynamic information. A core
Stephen> gateway (a "hub" in Michael's parlance) can download things
Stephen> to a satellite (maybe a new SPD and PAD, credentials,
Stephen> etc.), thus causing some traffic from the satellite to be
Stephen> sent to a different core gateway or satellite. In that
Stephen> circumstance, I think Michael's question is about whether
Stephen> the core gateway that a satellite initially connects (which
Stephen> I'll call the "initial core gateway") to should be expected
Stephen> to have or obtain all the information needed to configure
Stephen> the satellite or whether the initial core gateway can send
Stephen> the satellite to another core gateway where it can get more
Stephen> information. At least, that's how I understand Michael's
Stephen> question. Perhaps he can affirm or deny this
Stephen> interpretation.

You got my question correctly.
I'm gonna add a diagram so that everyone can agree.  (Those of you with
mailers that ignore text/plain; format=fixed, you need to copy this
email to Wordpad/vi, or it will be munged by your RFC-ignorant vendor)

In the requirements document, I think that we need establish some
nomenclature, such as "hub".  and "initial hub", or "core", as you wish.

Given that goal of this is to go from hub+spoke (generalized to
trunk+feeder.. In my spare time I'm actually a transit expert. True story)


  AB
   \  /
\/
 \  /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


Leaf A has traffic of leaf B.  It would otherwise go via Hub1(H1), Hub2,
and Hub3.

Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol,
magic will happen.  The question, *AT THE REQUIREMENTS* phase, is
whether a solution such as:

step1, H1 tells A that H2 is closer:

  AB
   \. /
\\   /
 \\ /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


step2, H2 tells A where B is:

  AB
   \. /
\\   /
 \\ /
  ++trunk1+--+trunk2 +-+
  | H1 |==|  H2  |===|  H3 |
  ++  +--+   +-+
 /\
/  \
   CD


pti


Stephen> Personally, I think that this question is premature. It
Stephen> presupposes too much about the eventual solution. That's
Stephen> why I think it should be answered in the solution not
Stephen> included in the problem statement. Apparently, Yaron
Stephen> doesn't agree with me. I'd like to hear more from him on
Stephen> this matter. Does he believe that all solutions to this
Stephen> problem (or at least all the good ones) must necessarily
Stephen> employ the model that I described above? What about a
Stephen> solution that doesn't rely on core gateways to refer
Stephen> satellites but instead has satellites querying for the
Stephen> information that they need? Or one that has some external
Stephen> entity (not the core gateway) configuring the satellites?
Stephen> In my view, there may be many possible P2P VPN
Stephen> solutions. However, I'm not an IPsec expert. Maybe this is
Stephen> the only practical approach. I'd like to hear views from
Stephen> Yaron and from others on this topic.

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

Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

[Michael Richardson]

> "Yoav" == Yoav Nir  writes:
Yoav> "direct endpoint-to-endpoint connectivity may not be possible
Yoav> if both endpoints are NATed" 

Yoav> Why?  There are several protocols (SIP/RTP come to mind) that
Yoav> manage endpoint-to-endpoint connectivity even when both are
Yoav> behind NAT. Why shouldn't IPsec endpoints do this? 

yes, sorta.
1) lots of SIP things actually fail through NATs, even when the entire
   path is under VoIP/IP provider's control.  (For instance Busy-Light
   Indicators are sent async).  

2) SIP with STUN fails to using the STUN (or TURN) gateway to relay all traffic
   when it discovers a restricted-cone NAT.  That means that SIP "works"
   by sending all traffic to a "data centre" (DC to use the terms in
   this ticket)

I think that this issue needs enumerate the kinds of reasons why an
endpoint may be unable to receive connections.   In particular, we may
in fact have to detect the various situations and automatically work
around them.  (One work around is sometimes to have the captive node
initiate the connection, something that we have the control mechanisms
to do)



pgpRlCgPBXG2i.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem.

[Michael Richardson]

I agree: it's not a "hard problem". It's an annoying problem, and the
lack of a dynamic solution causes poor experiences for users.

For a relatively static group of non-moving leaf gateways, even a very
large group, a bit of scripting could generate most of the full mesh
policy, and normal IKEv2 on-demand keying of links would bring up
tunnels as needed.

The reason to have an automatic system is because:
1) we have mobile nodes that we want to include (roadwarriors)

2) we have gateways behind NAT that can be hard to find.

3) we have machines/gateways that have non-transtive authentication
   mechanisms, and it would be very annoying to setup each leaf
   system with a trusted connection to the AAA system for
   authentication.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgpVZeVYf8gvb.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #217: Temporary credentials

[Yoav Nir]

On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote:

> 
>> "Geoffrey" == Geoffrey Huang  writes:
>Geoffrey> My initial inclination is to say that won't fly: that many
>Geoffrey> deployments still require preshared key authentication.
>Geoffrey> Rather, they would object to certificates because of
>Geoffrey> perceived complexity. That said, I could see arguments
>Geoffrey> that what we're discussing are already fairly
>Geoffrey> sophisticated topologies, so perhaps the certificate
>Geoffrey> allergy doesn't hold? 
> 
> Tero isn't proposing using certificates.
> 
> Tero is proposing that the gateway/hub provides each leaf node with a
> gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs
> of identity.  It would be used only for the leaf to leaf connection.  
> It would be retained for a convenient period of time and then destroyed.

Not just leaf-to-leaf, but also leaf to any other node, even if it's not a real 
leaf.

This is beginning to look a lot like Kerberos, no?

Yoav

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

Re: [IPsec] [ipsecme] #217: Temporary credentials

[Tero Kivinen]

Praveen Sathyanarayan writes:
> This works if there is only one Hub in the network. Scenario where
> multiple hubs in hierarchy or multiple Hub's that don't have
> hierarchical relation, this will not work.

I see no problems even if there is multiple hubs. There are lots of
different ways to do things, and we do not need to go to solution
space yet (one trust anchor per hub, sub-ca per hub, shared trust
anchor between the hubs etc).

On the other hand all of the solutions needs to take account the fact
that if there are multiple hubs. All depends also what kind of trust
relationship the hubs have etc.

With certificates there is a way to setup system so that hubs do not
need real time policy communications between them. With shared keys
the hubs needs to have real time policy communication, as the
temporary shared key generated by one hub, needs to be distributed to
other hubs needing it. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #217: Temporary credentials

[Michael Richardson]

> "Geoffrey" == Geoffrey Huang  writes:
Geoffrey> My initial inclination is to say that won't fly: that many
Geoffrey> deployments still require preshared key authentication.
Geoffrey> Rather, they would object to certificates because of
Geoffrey> perceived complexity. That said, I could see arguments
Geoffrey> that what we're discussing are already fairly
Geoffrey> sophisticated topologies, so perhaps the certificate
Geoffrey> allergy doesn't hold? 

Tero isn't proposing using certificates.

Tero is proposing that the gateway/hub provides each leaf node with a
gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs
of identity.  It would be used only for the leaf to leaf connection.  
It would be retained for a convenient period of time and then destroyed.

End users and leaf systems would continue to "authenticate" to the
gateway using the insecure legacy mechanisms that CTOs seem to prefer.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgpsGDoMWvCUf.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec